I often wonder if there should be a suite of tests that deliberately dont use well-tuned algorithms, or optimal ones, as the basis for benchmarks. In the real

I often wonder if there should be a suite of tests that deliberately dont use well-tuned algorithms, or optimal ones, as the basis for benchmarks. In the real world, people dont choose optimal paths in code very often. Or what was once optimal becomes suboptimal because the context changes. Supposing that a benchmark chose to do, say, bubblesort on an insanely large list. Would that lead to more insight around how the compiler would act in the real world? Or are the pitfalls so well understood that they are universally optimized away by the compiler's earliest stages or processing? If I were selling, say, Azul or some other alternative JDK, I might make a point of noting that it does a superior job of dealing with the code as it exists today, rather than as one might wish it to be.