3 ms·
10 years ago SQLite made a release dedicated to lots of microoptimisations that resulted in massive speed ups https://sqlite-users.sqlite.narkive.com/CVRvSKBs/5
by agilob 3y ago
10 years ago SQLite made a release dedicated to lots of microoptimisations that resulted in massive speed ups https://sqlite-users.sqlite.narkive.com/CVRvSKBs/50-faster-than-3-7-17 https://sqlite-users.sqlite.narkive.com/CVRvSKBs/50-faster-t...
Don't underestimate accumulation of small improvements.
- andrepd 3y agoHmm, but HN assured me that "premature optimisation is le root of all evil" (nevermind that that's an incomplete quote) :)
- forbiddenlake 3y agoWhat part of SQlite 3.8.7 are you saying is premature?
- trealira 3y agoI don't think they were saying that SQLite's optimizations were premature (since clearly they benefited the program as a whole), but that people conflate micro-optimization with premature optimization.
- Bjartr 3y agoThat optimization can be effective doesn't change that spending time on it too early is often problematic
- sfn42 3y agoSadly, HN was not able to help you understand what premature optimization is. What the SQLite team did was systematically measure the performance of their system, identify potential bottlenecks/inefficiencies, create and measure improvements to these bottlenecks and choose the better option. This is what we call optimization. Premature optimization is when you have no idea how your system really performs, but spend time trying to make it "better" without having a way to determine whether your change made any difference.
- windows2020 3y agoI thought premature optimization was when you decide to optimize a bottleneck but later end up rearchitecting and tossing it all anyway. I'd refer to what you're describing as messing around.
- sfn42 3y agoI'm not going to pretend to be some sort of authority on the subject, but personally I think both fit the bill. It is premature to optimize when you don't know how your system performs, and it can be premature to optimize if you might throw the solution away. However that last part isn't always the case. Maybe the reason you throw it away is that another solution is more performant - you had to optimize both to find that out. To me, the core of the issue is knowing what you're doing. If you know what you're doing then it's generally not premature. You have a reason for what you're doing. You're sure that you're working on the right part of the code and you are properly measuring the difference in a meaningful way.
- moffkalast 3y agoYeah, premature as in when you're designing the first prototype and haven't yet had real life usage data on what's the bottleneck.
- mratsim 3y agoPremature slogans are the root of all evil.