3 ms·

Also recall that a 50% speed improvement in SQLite was caused by 50-100 different optimisations that each eeked out 0.5-1% speedups. On phone now don’t have the

Also recall that a 50% speed improvement in SQLite was caused by 50-100 different optimisations that each eeked out 0.5-1% speedups. On phone now don’t have the ref but it all adds up.

boxed 3y ago
Many small improvements is the way to go in most situations. It's not great clickbait, but we should remember that we got from a single cell at some time to humans through many small changes. The world would be a lot better if people just embraced the grind of many small improvements...
toyg 3y ago
Marginal gains. https://www.bbc.co.uk/news/magazine-34247629 https://www.bbc.co.uk/news/magazine-34247629
Akronymus 3y ago
I tried searching for that article because I vaguely recall it, but can't find it either. But yeah, a lot of small improvements add up. Reminds me of this talk: https://www.youtube.com/watch?v=NZ5Lwzrdoe8 https://www.youtube.com/watch?v=NZ5Lwzrdoe8
- Topfi 3y ago
  Here is a source for the SQLite case: https://topic.alibabacloud.com/a/sqlite-387-a-large-number-of-minor-optimizations-improving-performance-by-more-than-50_1_46_32753417.html https://topic.alibabacloud.com/a/sqlite-387-a-large-number-o...
  - Akronymus 3y ago
    That looks like blogspam to me, rather than an actual source.
  - formerly_proven 3y ago
    https://sqlite-users.sqlite.narkive.com/CVRvSKBs/50-faster-than-3-7-17# https://sqlite-users.sqlite.narkive.com/CVRvSKBs/50-faster-t...
IshKebab 3y ago
That's true, and Rust compiler speed has seen similar speedups from lots of 1% improvements. But even if you can get a 2x improvement from lots of 1% improvements (if you work really really hard), you're never going to get a 10x improvement. Rust is never going to compile remotely as quickly as Go. Python is never going to be remotely as fast as Rust, C++, Go, Java, C#, Dart, etc.
- inglor_cz 3y ago
  Does it matter? Trains are never going to beat jets in pure speed. But in certain scenarios, trains make a lot more sense to use than jets, and in those scenarios, it is usually preferable having a 150 mph train to a 75 mph train. Looking at the world of railways, high-speed rail has attracted a lot more paying customers than legacy railways, even though it doesn't even try to achieve flight-like speeds. Same with programming languages, I guess.
  - fl0ki 3y ago
    What is the programming analogy here? Two decades ago, you could (as e.g. Paul Graham did at the time) argue that dynamically typed languages can get your ideas to market faster so you become viable and figure out optimization later. It's been a long time since that argument held. Almost every dynamic programming language still under active development is adding some form of gradual typing because the maintainability benefits alone are clearly recognized, though such languages still struggle to optimize well. Now there are several statically typed languages to choose from that get those maintainability benefits up-front and optimize very well. Different languages can still be a better fit for different projects, e.g. Rust, Go, and Swift are all statically typed compiled languages better fit for different purposes, but in your analogy they're all jets designed for different tactical roles, none of them are "trains" of any speed. Analogies about how different programming languages are like different vehicles or power tools or etc go way back and have their place, but they have to recognize that sometimes one design approach largely supersedes another for practical purposes. Maybe the analogy would be clearer comparing jets and trains which each have their place, to horse-drawn carriages which still exist but are virtually never chosen for their functional benefits.

Also recall that a 50% speed improvement in SQLite was caused by 50-100 different optimisations that each eeked out 0.5-1% speedups. On phone now don’t have the ref but it all adds up.

boxed 3y ago

Many small improvements is the way to go in most situations. It's not great clickbait, but we should remember that we got from a single cell at some time to humans through many small changes. The world would be a lot better if people just embraced the grind of many small improvements...

toyg 3y ago

Marginal gains. https://www.bbc.co.uk/news/magazine-34247629 https://www.bbc.co.uk/news/magazine-34247629

Akronymus 3y ago

I tried searching for that article because I vaguely recall it, but can't find it either. But yeah, a lot of small improvements add up. Reminds me of this talk: https://www.youtube.com/watch?v=NZ5Lwzrdoe8 https://www.youtube.com/watch?v=NZ5Lwzrdoe8

Topfi 3y ago
Here is a source for the SQLite case: https://topic.alibabacloud.com/a/sqlite-387-a-large-number-of-minor-optimizations-improving-performance-by-more-than-50_1_46_32753417.html https://topic.alibabacloud.com/a/sqlite-387-a-large-number-o...
- Akronymus 3y ago
  That looks like blogspam to me, rather than an actual source.
- formerly_proven 3y ago
  https://sqlite-users.sqlite.narkive.com/CVRvSKBs/50-faster-than-3-7-17# https://sqlite-users.sqlite.narkive.com/CVRvSKBs/50-faster-t...

IshKebab 3y ago

That's true, and Rust compiler speed has seen similar speedups from lots of 1% improvements. But even if you can get a 2x improvement from lots of 1% improvements (if you work really really hard), you're never going to get a 10x improvement. Rust is never going to compile remotely as quickly as Go. Python is never going to be remotely as fast as Rust, C++, Go, Java, C#, Dart, etc.

inglor_cz 3y ago
Does it matter? Trains are never going to beat jets in pure speed. But in certain scenarios, trains make a lot more sense to use than jets, and in those scenarios, it is usually preferable having a 150 mph train to a 75 mph train. Looking at the world of railways, high-speed rail has attracted a lot more paying customers than legacy railways, even though it doesn't even try to achieve flight-like speeds. Same with programming languages, I guess.
- fl0ki 3y ago
  What is the programming analogy here? Two decades ago, you could (as e.g. Paul Graham did at the time) argue that dynamically typed languages can get your ideas to market faster so you become viable and figure out optimization later. It's been a long time since that argument held. Almost every dynamic programming language still under active development is adding some form of gradual typing because the maintainability benefits alone are clearly recognized, though such languages still struggle to optimize well. Now there are several statically typed languages to choose from that get those maintainability benefits up-front and optimize very well. Different languages can still be a better fit for different projects, e.g. Rust, Go, and Swift are all statically typed compiled languages better fit for different purposes, but in your analogy they're all jets designed for different tactical roles, none of them are "trains" of any speed. Analogies about how different programming languages are like different vehicles or power tools or etc go way back and have their place, but they have to recognize that sometimes one design approach largely supersedes another for practical purposes. Maybe the analogy would be clearer comparing jets and trains which each have their place, to horse-drawn carriages which still exist but are virtually never chosen for their functional benefits.