Depends on the program. Any program that only or mostly calculates something will use 100% CPU. Only programs that wait for user interaction or use network, disk or some other external device heavily (and thus often wait for the network or the disk) will use less than that.
If you execute a perl program like
$a=<>;
and it still uses 100% while waiting for you to input something, then it is time to worry ;-)
| [reply]
[d/l] |
Just because it's perl it does not mean it cannot hog the CPU - it very much depends on what your script does.
E.g. a simple perl -e 'while(1) {}' can use 100% CPU if nothing else runs on your system.
If you need more help you need to post your script.
| [reply]
[d/l] |
Running at 100% is great. If a program isn't running at 100%, it's being slowed down from waiting for something (disk, user input, etc).
Update: Fixed phrasing to remove accidental implication that used CPU time is never wasted.
| [reply] |
If your program has something for the CPU to do, then it is absolutely delightful to find that the CPU is “100% busy” and that most of the available time is being given to your program.
If your program thinks that it is “idle,” then of course you have a problem. And, whatever that problem is, it is undoubtedly going to rest in your program. (Which probably isn’t responding to any inputs right now ...)
If the problem you are seeing is “recent,” ask yourself, “what happened ‘recently?’ ” One thing that can suck up a lot of CPU time is an “exception-handling loop,” in which something causes an exception, and maybe that same thing causes another exception to occur in the exception handling logic, and (for whatever reason...) the fail-safes that are supposed to prevent that are not working. It is also entirely possible that the root cause of the problem is actually external to the Perl environment but the wasted time is being, so to speak, billed to it. This is simply a situation that you need to carefully observe, analyze, and ponder. (If you can give us more details, perhaps some of us can ponder it with you. We’ll be happy to try ...)
| |
If you have a hot loop and want to consume less processor time at the expense of slightly slower processing, you could insert some well-placed sleep or select statements into said loop. You could also use blocking I/O or non-blocking I/O with sleeps rather than hard-polling I/O if you're using hard-polling I/O now. Other than that very general advice and pointing you towards profilers for better ideas of where your hot spots are, I can't really say anything else useful without seeing some code.
| [reply] |