> Premature optimization is the root of all evil -- Knuth
HN should have a bot that posts the full quote whenever this line is cited since it's so often abused.
"There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified."
Plus who said it was / should be used prematurely anyway?
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs
Isn't that essentially what I described? "Before seeking a third party library, be sure to check if the function is called many times or is taking a long time."
On the issue of this particular library: The problem is that you can do much much better by avoiding map, forEach and friends. The overhead of the function calls can be completely avoided by using a direct for loop at the callsite.
So yes, you may find it slightly faster to use this library rather than the native map, but with a small redesign you can avoid map entirely and get a massive performance win.
Swap to use a slightly faster function someone else already wrote, or rewrite your code. Seems like the latter is more guilty of premature optimisation if this library is fast enough for the particular use.
HN should have a bot that posts the full quote whenever this line is cited since it's so often abused.
"There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified."
Plus who said it was / should be used prematurely anyway?