There's no way that the FTL JIT gets involved on "typical javascript" which wouldn't run long enough.

They even say so on the blog post for the FTL JIT:

"Websites today serve large amounts of highly dynamic JavaScript code that typically runs for a relatively short time. The dominant cost in such code is the time spent loading it and the memory used to store it. "

Instead, it's more likely they have some weird benchmarks that they win on.

Everyone has their favorites, and reasons they claim they matter.

While it's been about year since i looked, most of them are just not large enough amounts of executing code to be reasonable benchmarks to argue about (they try to increase workloads bby increasing iterations, etc).

In truth, i can't fault anyone for the benchmarks they choose (except maybe regexp-dna), most are testcases extracted from the websites/programs they care about.

But this does not actually make them good benchmarks to optimize for, just good things to make fast.

The difference being, you want to pick representative benchmarks such that if you optimize for them, ideally all the cases you care about are made fast, not just the ones in the benchmarks.

For example, regex-dna (part of sunspider) is a benchmark about regular expression searching in DNA sequences (which is "not common" in webapps). To make it fast, most browsers have dedicated regular expression compilers tuned to it. This is pretty much worthless for webapps as a whole (the kinds of regexps involved do not generalize to the ones used in web apps), but it makes sunspider fast.

That's exactly what you don't want :)