Use fuzzy-matching to improve cache hit rates with PostScriptEvaluator

[Snuffleupagus]

This improves performance, without any noticeable regressions when running gulp browsertest --noChrome locally on Windows.
Testing the new pr5134 test-case locally in the viewer:

• With the master branch and isEvalSupported = true, page 2 renders in approx. 350 milliseconds.
• With the master branch and isEvalSupported = false, page 2 renders in approx. 1550 milliseconds.
• With this patch and isEvalSupported = false, page 2 renders in approx. 700 milliseconds.

Hence this obviously isn't enough to close the performance gap, but it may still be helpful.

[Snuffleupagus]

/botio browsertest

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Received

Command cmd_browsertest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.241.84.105:8877/95008531e66a0fd/output.txt

[moz-tools-bot]

From: Bot.io (Windows)

---

Received

Command cmd_browsertest from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.193.163.58:8877/986f8a3849056f7/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Failed

Full output at http://54.241.84.105:8877/95008531e66a0fd/output.txt

Total script time: 22.07 mins

• Regression tests: FAILED

  errors: 18
  different ref/snapshot: 20

Image differences available at: http://54.241.84.105:8877/95008531e66a0fd/reftest-analyzer.html#web=eq.log

[moz-tools-bot]

From: Bot.io (Windows)

---

Success

Full output at http://54.193.163.58:8877/986f8a3849056f7/output.txt

Total script time: 25.63 mins

• Regression tests: Passed

[Snuffleupagus]

@calixteman Any opinions about this? (Obviously "this is a stupid idea" is a perfectly valid response :-)

The PDF document referenced here is a particularly "bad" one, given the PostScript functions it contains, and in most cases the functions aren't slow enough to really be an issue in practice.

My thinking here is that if we manage to improve the performance of PostScriptEvaluator enough, we may be able to remove the PostScriptCompiler which has the only remaining new Function(...) usage. (As we saw in the recent security issue, that sort of code-pattern is best avoided.)

[calixteman]

@calixteman Any opinions about this? (Obviously "this is a stupid idea" is a perfectly valid response :-)

Yeah, I read this patch few months ago now, and I was a bit doubtful, not really doubtful but something around so-so, doubtful, why not, ...

That said I'd really like to get rid of this eval and I had few thoughts:

• try to improve the current implementation in pure js;
• implement in C/Rust a postscript evaluator and compile it into wasm;
• if the perfs aren't enough, directly compile the postscript function into wasm code.

I tried the first one only, I saw few things to improve but unfortunately, the perfs were bad and I didn't see that much room for improvements.
Of course the 3rd possibility would be the faster but it's probably a bit more complex and prone to bugs but it can be implemented in pure js.
So maybe the second option would be more reasonable, probably in Rust for the safeness.

To answer to your question, maybe we can try it and see how it behaves in the wild, and if we've "too much" negative feedback, we can revert the patch and wait for a better solution.

That said if you want to try to implement one of the two ideas above (or an other idea of course), feel free to do it, just tell me to avoid to work both of us on it.