2. Consider any algorithm of roughly linear complexity (this probably applies to N lg N as well): the only way to make it significantly faster now is to improve parallelism (whether making it so the CPU can exploit ILP, running multicore, or running on a GPU). In 1992, you could make things run significantly faster by just waiting until it was 1994.
In the late 90s a couple of companies, including Microsoft and Apple, noticed (just a little bit sooner than anyone
else) that Moore's Law meant that they shouldn't think too hard about performance and memory usage... just build
cool stuff, and wait for the hardware to catch up. Microsoft first shipped Excel for Windows when 80386s were too
expensive to buy, but they were patient. Within a couple of years, the 80386SX came out, and anybody who could
afford a $1500 clone could run Excel.
As a programmer, thanks to plummeting memory prices, and CPU speeds doubling every year, you had a choice. You
could spend six months rewriting your inner loops in Assembler, or take six months off to play drums in a rock and
roll band, and in either case, your program would run faster. Assembler programmers don't have groupies.
So, we don't care about performance or optimization much anymore.
— Joel Spolsky, "Strategy Letter VI" (2007)
Also to some extent it’s just that we’ve pretty well standardized on algorithm implementations. Thinking about the relative merits of a BST vs a red-black tree vs a hash table with bucketing or open addressing or whatever just doesn’t happen as often when the standard library has one implementation and not choosing it would cost you a week of implementing testing and justifying the decision to your colleagues.