Re^3: Speeding up data lookups

[QM]

IOW: think first, then profile.

Yes, exactly. But that's assuming that we took time in the first place.

I would go further and suggest a conscious design phase in the beginning. If it's not a one-shot, and speed is important, then start with requirements, design to them, possibly experimenting when choosing between implementations.

But given an existing system that runs too slowly, profile it now. If it's a bubble sort on a million records, that will be highlighted in million candle spotlights.

The reason I suggest Devel::SmallProf is because it is more granular than the other oft-mentioned profilers. If the program is one giant subroutine, Devel::DProf will indicate that most of the time is spent in that routine. Devel::SmallProf will indicate which line of code is the worst, the next worst, etc. (for certain values of "line of code").

So I agree with you, "Think before Do". But sometimes "Do" has already happened, and it's generally more efficient to the let instrumentation tell you where to start looking. It may be wrong, but I'd bet it's right often enough to warrant first action.

[suaveant]

Absolutely... in a system of any size there tend to be many different parts, and it is good to know where you are getting hit the hardest.

Of course.. when I am playing in an area I am not too sure of I like to run some mockups and profile them to actually see if things I think will be faster actually are ;)