Browsermark: String-Filter

Still following the chain of Browsermark's "next_test" links, we arrive at the String-Filter test at http://web.basemark.com/tests/2.1/benchmarks/javascript/string_filter/test.js. As usual, the file appreciates beautification in order to achieve its full human readability potential.

The test takes a list of 250 movie titles beginning with "The Shawshank Redemption (1994)" (I wonder where they got that from?) and tests them against a series of regular expressions of the form "(1900)", "(1901)", and so on. Apart from that list, the entire benchmark is just this:

[1]  results[c] = [];
[2]  var e = new RegExp("/.*(" + (1900 + (iteration_index % 100)) + ").*/i");
[3]  for (var d = 0; d < this.movies.length; d++) {
[4]    if (e.test(this.movies[d])) {
[5]      results[c].push(this.movies[d]);
[6]      counter++
[7]    }
[8]  }

So we have another micro-benchmark on our hands: it tests creation of regular expression objects ("new RegExp(...)" in line 2) and calling a RegExp's .test() function on a string ("e.test(...)" in line 4).

An interesting (to put it politely) choice is the placement of the "counter++" statement in line 6 inside the if-block. The test isn't counting the number of RegExp objects created, or the number of .test() calls performed, but the number of matches returned by those .test() calls. With enough iterations, this is harmless, because the same input strings are looked at over and over again, so even though some iterations will have zero hits and some have many, in the long run the number of encountered hits will be proportional to the number of tests performed. However, on a slower device, or if the string set was larger or non-repeating, this would be a source of considerable skew.

There isn't much else to say about this test. It does exhibit a few of the bad ideas we've seen in other Browsermark tests, but due to sheer luck they're not that hurtful in this case: since testing 250 movie titles against a regexp isn't quite as short-running as the other tests, the "results" list doesn't grow quite as much, and taking the current time after each iteration also produces less overhead in relation to the workload.

Conclusion:
It's a boring micro-benchmark for "new RegExp" and "RegExp.test()". There are probably very few real situations where the performance of these two operations in isolation matters, so this is a far cry from Browsermark's claim to "Measure Real-Life Browsing Performance".