Tim Chase on Nostr: nprofile1q…rsr9k There's definitely a balance to be struck. I see a lot of modern ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqt7dmr2xue8zaxsxhy2xkdja0nx6f8cu8y8l7hfksw98y773djkgqqrsr9k (nprofile…sr9k) There's definitely a balance to be struck.
I see a lot of modern software using GB of RAM and gobs of CPU (glares at Electron apps) to run, or build-steps taking ghastly amounts of time (recently several CLI utilities written in Rust taking >1hr to compile, on admittedly-old hardware that still blows away anything I had in the early 2000s where compilation times were tolerable)
On the other hand, it's awfully nice to have interpreted (or semi-compiled) languages like Python or Ruby where you don't have to think much about memory management and the standard library gives you oodles of tools by default (having built-from-scratch more than my fair share of standard data-structures/algorithms in C, it's nice to just have them right there)
But the most important thing from both our posts is that profiling is paramount. If that interpreted code is fast enough, let it be. And on the other side, optimizing byte-vs-int storage is useless if you're poorly managing GB of RAM elsewhere, or you're using some time-consuming O(n²) algorithm where you could use an O(1) or O(logₙ) routine.
I see a lot of modern software using GB of RAM and gobs of CPU (glares at Electron apps) to run, or build-steps taking ghastly amounts of time (recently several CLI utilities written in Rust taking >1hr to compile, on admittedly-old hardware that still blows away anything I had in the early 2000s where compilation times were tolerable)
On the other hand, it's awfully nice to have interpreted (or semi-compiled) languages like Python or Ruby where you don't have to think much about memory management and the standard library gives you oodles of tools by default (having built-from-scratch more than my fair share of standard data-structures/algorithms in C, it's nice to just have them right there)
But the most important thing from both our posts is that profiling is paramount. If that interpreted code is fast enough, let it be. And on the other side, optimizing byte-vs-int storage is useless if you're poorly managing GB of RAM elsewhere, or you're using some time-consuming O(n²) algorithm where you could use an O(1) or O(logₙ) routine.