I’ve wondered why we don’t typically use algorithms that will self-adjust when we have so many VMs that can do all sorts of statistical analysis. We know that q

I’ve wondered why we don’t typically use algorithms that will self-adjust when we have so many VMs that can do all sorts of statistical analysis. We know that quicksort is inefficient on smaller and mostly-sorted lists so we oftentimes switch to selection sort below 20 items or so, but we typically have libraries that have statically picked this behavior as directed by their developers instead of over time selecting the more appropriate algorithm. Sure, if you’be never seen the data before there’s not a lot you can assume, but if over a lot of executions your VM can perform native code substitution and replace certain sections of code out based upon runtime profiling in HotSpot why can’t we come up with heuristics that say “just use a list instead of a hash table until runtimes to access start getting slower than n, in which case reallocate the data to a hash table, btree, or a heap depending upon which operations are most sensitive to system design parameters.” A lot of problems seem like we’re repeating ourselves writing the base algorithms and gluing things together when we really should be investing problems around resource constraints and system trade-offs and priorities. Then we could run test suites against these systems to determine how well they’d meet certain guarantees programmed in.