Depending what your code is doing, it could either be that your code requires 50% of thr cpu in order to do the work it is doing OR, it could be that the way your code is doing what it is doing it less efficient than it could be and that by switching to a better algorithm, you maybe able to improve it.

Often just the right choice of algorithm can make a world of difference. In effect, the better compiler you need is the one compiling (ie. typing :) the source code.

Why not profile your code (see Devel::Dprof or Devel::SmallProf ), and when you know where your code is using the most time, post that here and see if we can't help you optimise that.

It may be that you might need to recast some small parts of your program into Inline::C) to improve things.

That said, usually, an efficient algorithm uses more cpu than less--it just finishes more quickly. It could be that you could reduce the cpu loading your program generates by the tactical inclusion of a short sleep statement into one or more of your loops. This is especially true if your program spends a lot of time polling, waiting for something to happen.

Without a description of the program, or preferably, sight of the code, it is difficult to speculate what approach might be the best,

Perl is not compiled, and there are no compilers for it, at least not for production use. Maybe, maybe, Nicholas Clarks When Perl is not Quite Fast Enough can be of help for you, but the first approach is always to optimize the program itself instead of looking for a different Perl interpreter!

Also consider buying a faster CPU or faster machine - it may be cheaper to buy bigger hardware than to look at the program and change it.

Perl is not compiled, and there are no compilers for it, at least not for production use.

While the degree of approximation of this answer does indeed make it an appropriate one to the question being asked, perl code is compiled, much in the same fashion in which Java code is compiled into bytecode. Just to be fussy...

As Corion pointed out, Perl is an interpreted language. When you run a Perl script, it goes through a "compilation" stage, but that only takes it to a stage that is easier for the interpreter to deal with. And all this is contained within the single perl executable. There are much more recent versions of Perl available. ActiveState currently is dispensing version 5.8.6.

If your problem is startup time, you could convert your script to something that is "always on", just waiting (blocking) for input. Or if we're talking about CGI, you could switch over to mod_perl, which eliminates the startup cost of your script.

If your problem is runtime speed, profile to find the bottlenecks, and then rework the key segments of code that are slowing you down. You may find that the script is IO bound rather than CPU bound. Or you may find that there's a really poorly written algorithm somewhere that is taking O(n^2) (or worse) time. If you can rework a key algorithm from O(n^2) time to O(n log n), you gain a magnitude of better time efficiency. Convert O(n log n) to O(n), to O(log n), to O(1), and each time you realize a dramatic improvement in runtime speed. Maybe there's a situation where you should be using a hash instead of grepping a list, etc. But definately profile before optimizing so you'll know where to focus your efforts, and which small fish to let go.

The problem is not the execution time but the problem is that it is taking 50% of CPU for each and every program it runs, irrespective of the code for which it is running. I am not able to any application say any other execution of perl file for example. I have also tried with the Active Perl 5.8(Latest Version) but the problem remains the same. Please suggest me what should I pursue for.

50% of CPU doesn't say anything at all. If only 50% of the CPU is used, you're underusing the system. Remember that the fraction of CPU time gets allocated to a process is a task of your kernels scheduler, and the sceduler takes into account a lot of variables to decide how much time a process gets. And each OS has its own scheduler - which some OSses, there's even the possibility to tune it. A not complete list of things taken into account:
• How many processes there are in the run queue.
• How many processors there are available to the OS.
• The process' priority.
• How long the process has been running.
• How long the process has been waiting for a time slot.
• If the process is doing a page fault, is it a minor or a major fault?
• Interrupts.
• Blocking system calls.
• ...

well, then you perhaps don't need to make your script faster but just execute it "slower"... could it be the solution to just run it in a lower priority class?

see help start for details, e.g.

There is also an implementation of nice available for windows here. That is a port of the unix/linux-utility nice, which can control the priority of a program at runtime.


holli, regexed monk

For any given version of Perl there is only one source code (any patches that might have been applied in the creation of a binary distribution notwithstanding) so the chances of different binary distribution actually making any difference in regard to resource usage are pretty slim - it is possible that a different C compiler (such as Borland) might make different optimizations and might make a perl binary that performed slightly different, but in general the pattern of resource usage is down to the way that perl works (and the design of your program) rather than the way it was compiled.

/J\

Best enhancement to that system is apt to be pushing RAM to 512 or 1 GB.

Not a perl solution... and those above that are may provide big gains, but just cuz MS sez 256 is minimum RAM for XP doesn't mean it can run happily in 256. Suspect a big piece of your CPU useage is moving stuff to and from swap.

If this were happening to me, I'd look for neverending loops that hammer the processor, but, you say it's happening to all the script you run? That's odd, unless you're reusing the code that's causing the problem. :)

Can u plz suggest me any other compiler for windows which consume less CPU and executes programs faster as Active Perl. My System configuration is Windows XP,PIV 2.4GHz,RAM 256.

Short answer no. 2: don't blame perl (the interpreter) nor Perl (the language), blame your code. Well it may be fine, after all, but as already explained by other monks in finer detail you should really try profiling it or asking here for suggestions. The overall impression I got from your post _suggests_ me that this is indeed the case...