4 ms·
I get what you're saying. But I think there's a limit. IME there are platforms (Ruby, JS, others) that have such high method dispatch overhead that the fastest
by ssmoot 11y ago
I get what you're saying. But I think there's a limit.
IME there are platforms (Ruby, JS, others) that have such high method dispatch overhead that the fastest "algorithm" is generally the one with the smallest stack-trace for 99% of problems.
It can be a very very very difficult bar to overcome.
I've only ever seen algorithm choice play a meaningful role in traditionally fast/compiled languages. YMMV.
- tomp 11y agoAbsolutely not. Even if you write an interpreter in Python, a hashtable lookup (O(1)) leading to an O(n) algorithm will be faster in this interpreted language than a O(n^2) algorithm using the O(n) list lookup in C; for a sufficiently high n, of course, but it's not uncommon to have n of several million these days.
- ssmoot 11y agoIt's absolutely very uncommon to have a single collection of several million in the languages I mentioned in the web-app space IME. Anyways, that's my experience with Ruby. Since each allocation (at the time) took 23 bytes of memory, even object graphs c# or Java might consider fairly modest (say loading 10,000 rows with a dozen fields into an Array<User>) would burn through a silly amount of memory comparably and probably trigger a GC cycle. We're talking nanoseconds on the compiled side vs hundreds of milliseconds. It takes a very very high N to overcome that sort of issue. One you might run into in scientific computing a lot more frequently, but not the sort of issue you'd often (if ever really) run into writing a web-app.
- tomp 11y agoOk, you're probably right about Ruby and JS. I was thinking about Python, which I would consider in the same class of "slow" (wav) languages, but it's also quite common to do data processing and machine learning in it.