|
Notes |
|
|
|
|
|
|
|
|
It does not appear to hang, just takes some time to run the javascript |
|
|
|
(0000976)
|
|
Michael Drake
|
2015-10-21 22:14
(Last edited: 2015-10-21 22:26) |
|
Uploaded a kcachegrind profile; duktape-unicode-regex.png
As I understand it duktape's implementation of Unicode case insensitive regular expressions is written for low memory usage, rather than for speed.
As such its taking almost 90% of the time to start NetSurf with that page just to do the regular expressions. In the remaining 10% of the time NetSurf starts, decodes all the html and css, generates the dom, does all the non-regex javascript, selects styles for all the elements, lays out the page, renders it, decodes the images and renders them, and then quits.
So there's a lot of room for improvement. We've already reported the issue upstream to the duktape maintainer.
|
|
|
|
(0000979)
|
|
Michael Drake
|
2015-10-24 14:47
(Last edited: 2015-10-24 14:48) |
|
From the duktape maintainer:
< svaarala_> tlsa: thanks - i'll try to figure out a minimal fix for this issue as soon as i get some free time
< svaarala_> tlsa: a more comprehensive solution would be to provide a speed optimized unicode implementation in general, but this particular case is much worse than other places
< svaarala_> tlsa: actually, i wrote a quick branch which uses a 64k entry lookup for the regexp canonicalization
< svaarala_> tlsa: the cost is 128kB of footprint but it makes a 30 second pathological test run in 30ms
< svaarala_> tlsa: i don't plan on this being the long term solution but this might fix your immediate issue if that 128k is not too much?
< svaarala_> tlsa: anyway, if you're interested, i'll push the test branch and it'd then be interesting to know if that fixes the netsurf issue
< svaarala_> tlsa: at the very least it'd tell us that this is the only real problem in those cases
< svaarala_> tlsa: here's a snapshot with a prototype fix included: http://duktape.org/snapshots/duktape-1.3.99-20151022195439-v1.3.0-138-g4045393-regexp-canonicalize-lookup.tar.xz
< svaarala_> tlsa: and here's the pull: https://github.com/svaarala/duktape/pull/411
|
|
|
|
|
Using the prototype duktape fix, the performance is much better. Most of the time is still spent processing javascript, but its not dominated by regex work.
I've attached another profile image which shows the improvement: duktape-fast-regex.png
From the 2 images we can see the total instruction fetch cost is reduced to 12% of what it was (from 60 billion to 7 billion). |
|
|
|
|
|
|
|
|
|
This problem seems to have reappeared after I upgraded from v3222 to 3244. |
|
|
|
|
|
|
|
|
|
Confirmed fixed in 3.4 release |
|
duktape-unicode-regex.png (472,919) 2015-10-21 22:07