Patch to increase performance of escapejs

[josephdrose]

The current implementation of escapejs iterates through a list of values and does a string.replace(...). The patch here creates a regular expression with the values and uses a dictionary to do the replace upon the match. Local testing shows the new implementation to be faster; the script used to perform this test is also attached.

[gisle]

Patch update to make it pass the 'defaultfilters' test (added match on \u2028\u2029)

[gisle]

On my machine using josephdrose's benchmark script this approach doubles the speed of the escapejs() function.

A problem with the patch is that the set of chars to match now has to be maintained in 2 places: both where _base_js_escapes and _js_escapes_re are set. It would be an improvement to generate the re from _base_js_escapes.

[gisle]

Even faster version without double maintenance of keys

[gisle]

Updated benchmark script

[gisle]

I've updated the patch with a new version that is better because you don't have to maintain the keys in 2 places and is faster because all chars to be replaces is matched by a single regex-charclass. I've also attached a new benchmark script.

Unfortunately there are cases where the new approach actually is slower. This happens when we try to escape long strings with large fraction of chars that need to be escaped. It still think this patch is worth to apply because it should make this function 2-5 times faster on most "real" strings.

When I run the escapejs_benchmark.py script here I see:

11.5x speedup 2.1s vs 0.2s 'xxxxx'

5.4x speedup 3.9s vs 0.7s 'xxxxxxxxxx...'
2.9x speedup 2.2s vs 0.8s ""
5.0x slowdown 10.0s vs 49.6s "..."
2.4x speedup 2.5s vs 1.0s "Hello, I'm..."

[gisle]

With proper wikiformatting it looks like :-(

 11.5x speedup  2.1s vs 0.2s 'xxxxx'
  5.4x speedup  3.9s vs 0.7s 'xxxxxxxxxx...'
  2.9x speedup  2.2s vs 0.8s "'''''"
  5.0x slowdown 10.0s vs 49.6s "''''''''''..."
  2.4x speedup  2.5s vs 1.0s "Hello, I'm..."

[jkocherhans]

This isn't critical for the first 1.2 release. Bumping from the milestone.

[patchhammer]

0001-Faster-escapejs-11778.patch fails to apply cleanly on to trunk

[Dmitry Jemerov]

Updated patch to latest trunk (r16344), updated expected test results due to the changes in escapejs output (now it uses \x## notation instead of \u#### for characters with low ASCII codes). The output change looks like a backward compatibility concern to me, although the new output is more compact than the old one (which saves a tiny bit of traffic).

[Dmitry Jemerov]

Patch against r16344 with updated expected test results

[Claude Paroz]

This has probably already been solved by [44767f2caf028d8].