Job van der Zwan

Goodness, that was hard... I mean, about as hard as I expected, but still. In the end the trickiest part was expanding the number of bits at the right pace,...

The benchmarks I used, on JSBench: http://jsbench.github.io/#e25c445d987295b0114407e457dde9ad http://jsbench.github.io/#4a2ca3e9e3e9ee544f5b76acc7699ef8 If people could please test this out in their own browsers, that would be very useful.

In the infamous words of Columbo: _just one more thing..._ I think that that loop unrolling I mentioned earlier is not quite as hard as anticipated (although still hard, and...

Answer after testing: nope, both are slower. So, sticking to the previous version of reading in characters one at a time. Also, I realised my benchmarks were flawed: I measured...

Last bit of optimising, I swear! I can quit when I want to! Anyway, the `aaaaabaaaaacaaaaadaaaaaeaaaaa` case is still slower (edit: _for Chrome_), but the gap has been reduced from...

So remember how I said I can't think of any more ways to improve performance? Well, I came up with one possible improvement, but it doesn't seem to work out.....

So I've been trying if the trie-approach might work for `js-search` as well. At first it seemed to be slower, until I tried an array-based approach: > > - typically,...

Ignore my previous claim: jsbench seems to have lots of overhead messing up the benchmarks due to GC pauses or something, because I just tried again on jsperf and the...

Well, it definitely might be, but perhaps it makes more sense to have a separate map version and let people use polyfills in their build system. Otherwise you get code...

Nice! I'm also curious what the JavaScript version of compiled Haxe lookes like