Re: Performance improvement in perl scripts

The “80/20 rule” applies all over the place when it comes to talking about computers: such as, “80% of the time is spent in 20% of the code,” or, “80% of the code is [almost] never used anyway,” and so on.

Having decided upon a reasonably efficient algorithm, for what the program actually needs to do (and no more...), measure to see the particular spots where the program is running both frequently and slowly.

Human-perceptible slowdowns are almost always going to involve input/output: either inefficient operations against actual files, or, perhaps more likely, wasteful use of memory which causes thrashing.

Performance improvements are usually trade-offs: you get something, you pay something. That decision will be yours.

Finally, there is this august maxim from the venerable Elements of Programming Style: don’t “diddle” the code to make it faster .. find a better algorithm. I suggest that this notion should lead you very frequently to CPAN; to the assumption that a “better algorithm” probably exists, and that a CPAN author probably found it.

actually

Replies are listed 'Best First'.
Re^2: Performance improvement in perl scripts by JavaFan (Canon) on Apr 26, 2012 at 12:40 UTC
to the assumption that a “better algorithm” probably exists, and that a CPAN author probably found it. Maybe. But do realize that something being on CPAN only means that a author found a algorithm. It may be correct, it may not be. It may be better, it may not be. The more times a wheel has been reinvented, the chance one of the authors has a better algorithm increases. It's also going to be harder to pick the better one (as there will be more choice). Do also note that many CPAN authors try to be "complete", and engineer their provided solution to be as general as possible. That usually comes with a price. In fact, if performance really matters, not using CPAN is often the better solution: now you can create something that's tailor made for your environment, and you don't have to pay a price for being more general.	[reply]
Re^3: Performance improvement in perl scripts by BillKSmith (Monsignor) on Apr 26, 2012 at 14:35 UTC
Even when we choose not to use the module, the time spent looking for it is seldom wasted. Module documentation often reveals special cases or other aspects of the problem which we had not thought of. True, modules may not be correct. The same can be said for own code (especially code optimized to a different standard). At least, the module has withstood the criticism of a fairly large base of users.	[reply]
Re^4: Performance improvement in perl scripts by JavaFan (Canon) on Apr 26, 2012 at 14:45 UTC
At least, the module has withstood the criticism of a fairly large base of users. What's the basis for this argument? There's nothing on CPAN that guarantees, enforces, or even promotes that uploaded modules first get a large base of users, or has to withstand criticism. I can upload any code I want, and when you are browsing CPAN, you have no idea if the code has any actual users, or whether there was any criticism, and if so, what I have done with it. Please, we should stop assigning magic properties to CPAN, or code that's on CPAN. CPAN is a storage and distribution vehicle. Nothing more than that. There are good pieces of code on CPAN, and there's crap. But the mere fact that code is on CPAN proves absolutely nothing of its usefulness or quality. As a programmer, you should recognize that. A programmer who totally ignores CPAN is wasting a lot of effort. But a programmer that blindly considers anything on CPAN as quality can actually be quite harmful for the environment he's working in.	[reply]