| [reply] |
| [reply] |
Well, frankly id say that this is the last advice to give. Much better is a period of reflection and analysis, followed by some research. Then you put together a system using sound algorithms. Then finally, when you need to cream some extra speed out of the system, then you do profiling.
The point is that if you are using Bubble Sort to reorder a million record file in random order you can profile it all you want without ever making it go as fast as a mergesort would have.
IOW: think first, then profile.
---
$world=~s/war/peace/g
| [reply] |
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.
-QM
--
Quantum Mechanics: The dreams stuff is made of
| [reply] |
| [reply] |