How to optimize CPU and Memory usage?

[ThelmaJay]

Dear Masters,

How can I spot optimization spots in my code?

I want to reduce CPU usage and memory leaks. How can I spot them?

[davido]

Do you have memory leaks? They're harder to come by in Perl code than in a language like C or C++, though still possible. It's pretty old, but there is Devel::LeakTrace, if you believe you have one you need to track down. For me sometimes a first step is to create a test that puts a module through a lot of iterations, and then just observe "top". Old fashioned, but low effort. If that turns up anything interesting, then I spend the time to dig deeper. The two most common sources of memory leaks in Perl are circular references, and buggy XS code.

As for CPU optimization, profile first (Devel::NYTProf), and if you really do have a problem somewhere, then you can Benchmark alternatives.

[dHarry]

Devel::NYTProf is a good of looking for improvements. Chances are you identify bottlenecks in your code.

Posting your code, e.g. on your scratch pad, and asking somebody to review it can also help.

Cheers

Harry

[CountZero]

It is a noble effort to be frugal with CPU cycles and memory, but actually with the CPU probably spending most of his time doing nothing or at least far below its maximum and memory being cheap, I find such hunt for optimization less and less necessary.

Premature optimization is the root of all evil (or at least most of it) in programming. (D. Knuth, 1974 Turing Award Lecture, Communications of the ACM 17 (12), (December 1974), p. 671)

[BrowserUk]

CPU and memory that is not being utilised is still consuming energy; and that is money.

Your attitude is like that of the guys that designed US cars in the 70s were every shopping car weight 2 tons, had a 500CI V8 and got 7 miles to the gallon. In 1974, oil cost 3 dollars a barrel; by 1984 is was almost 40 dollars a barrel. Today, it is well over 100 dollars per barrel.

[CountZero]

You are right about cars, but I do not see the analogy with computers.

What is the benefit of spending hours in optimizing and then shaving off 2 seconds and 100 MByte from a program that before optimization ran 5 seconds and used 250 MByte. Do you switch your computer on and off for each script you want to run?

That is what I mean with "premature" optimization.

My laptop is "on" the whole day I am in the office and the scripts I run really only use spare cycles and empty memory. How much power does a computer need to run an email client and an editor or a spreadsheet? If I can push CPU use above 25% with my "normal" work, I will have blisters on my fingers (and more typos than correctly typed words).

[sundialsvc4]

Obviously, both points-of-view are correct.   You, BrowserUK, are constantly squeezing every ounce of capacity and performance out of a program ... because you quite legitimately need to, and you are obviously quite good at it.   But the opposing point is at the same time equally valid:   that Moore’s Law shows no signs of slowing down.   So, it is simultaneously possible to “make poor engineering decisions” in both directions, because there are two costs here:   the cost of computer hardware, and the cost of computer programmers.   Both points-of-view are true and correct.   It entirely depends on the context ... and the OP so-far said nada about this.   So, we really don’t need to argue about that point, do we?

Addressing the OP’s original question, I would suggest these rules-of-thumb:

1. First, objectively validate that there is a valid business issue here.   Beautiful cars and butt-ugly ones can be seen traveling side-by-side on the highway (and you, of course, are stuck behind the one that’s burning oil ... koff, koff), and both of them will arrive at their destination at the same time, thereby achieving the same business purpose.   If one of them burned twice as much gas getting there, their owners might have no reason at all to care.
2. Second, determine if the problem should be solved with software, or hardware, or both.   Of the two, software is vastly more expensive ... and vastly more vulnerable(!) to negative consequences arising from “any sort of change whatsoever, no matter how well-intentioned.”   Chips are cheap, and getting cheaper all the time.
3. If you make it to point #3, it’s time to determine where it hurts the most.   Which program or program(s), under what conditions (i.e. doing what?).   Where is the most bang for the buck?   Which change is likely to produce the most-maintainable future state?
4. Now ... measure.   Profile the thing.   Do not guess about anything, because you are undoubtedly wrong.
5. Next:   “which one will it be ... speed? ... or space?”   CPU ... or Memory?   You cannot have it both ways.   Ever.
6. “Don’t ‘diddle’ code to make it faster ... find a better algorithm.”   That maxim from The Elements of Programming Style (Kernighan & Plauger) is still true.   To make your program run significantly faster, or to use significantly less memory (pick one), you will have to devise (or find) a better algorithm.   There is, I aver, no other way to do it.
7. Now ... prototype.   Put your pinkie-toe into the water and keep your fourth toe dry.   Set up an expendable test-case to demonstrate that your idea is both correct and useful under real conditions.
8. Now implement your change ... but you’re not done yet!   You have just made major changes to the program.   Now, you must construct test cases to prove that the old and the new versions produce identical results in all cases, and that your expected improvements were in fact realized.

[bulk88]

Recompile your perl, see my advice at http://www.nntp.perl.org/group/perl.perl5.porters/2013/10/msg208618.html.