I wonder if I should recompile a perl without those options to get better performances

If you aren't having performance problems, you shouldn't be worrying about that. It's a common mistake to try to enhance performance without a "real" reason to do it. Better waste your efforts in some other things, and worry about performance when it becomes a problem.

nonsense.

G:\>perl -h

Usage: C:\Perl\bin\perl.exe [switches] [--] [programfile] [arguments]
  ...
  -c              check syntax only (runs BEGIN and CHECK blocks)
  ...
[download]



holli, /regexed monk/

Er, no. What he meant was that when the perl was built the DEBUGGING symbol was defined which causes extra code to be compiled in perl to support the -D command-line switch. This can't be turned off at runtime.

/J\

The runtime cost of a debugging-enabled perl varies depending on the sort of processing you're doing. Most of the time the cost is negligible, but in some cases it can be quite significant (eg if some debug variable is being malloced and released in a tight loop).

I'd suggest building a non-debugging perl and doing some comparative benchmarks on your own programs to see if the difference would be significant in your case.

Hugo

I'd just add that compiling in threading exerts a not insignificant runtime cost. If you never use threading having an unthreaded perl is nice.

recompiling /usr/bin/perl will cause problems if some system tools depending on perl will modules that need recompilation.

For example, from my own experience, after recompiling /usr/bin/perl on Mandrake 10.0 I got incompatible modules and many system tools indeed stop working.
In this case better approach was to update Perl from distribution provided with same vendor (rpm package).

Vadim.