Faster JBIG2 decoding for Firefox

[fkaelberer]

This PR improves decoding speed of JBIG2 (scanned black & white) images on Firefox, and so improves #2909 and #3448.

Speed was increased via

• inlining two of the most-called functions, and
• converting a sparse array of context objects into a typed array for faster access.

The rendering speed on Firefox 24a2 is increased by factor 1.5x-5x, and by 1.5x in FF25. Chrome28 speed is unaffected.

The timings seem to be a little inconsistent though (maybe because they are measured in a VirtualBox VM?). On Windows, decoding times decreased by factor 1.25 on FF22, and by factor 2 on FF25 nightly.

Can somebody confirm the speedup?

Firefox 24a2:

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20130803 Firefox/24.0
-- Grouped By stat, browser, pdf -- 
stat         | browser | pdf       | Baseline(ms) | Current(ms) | +/-   | %      | Result(P<.05)
------------------------------------------------------------------------------------------------
Overall      | firefox | issue1810 | 6123         | 2213        | 3910  | 63.86  | faster       
Overall      | firefox | issue2909 | 20840        | 4297        | 16543 | 79.38  | faster       
Overall      | firefox | issue3448 | 1811         | 1167        | 643   | 35.54  |              
Page Request | firefox | issue1810 | 3            | 3           | 0     | 3.12   |              
Page Request | firefox | issue2909 | 42           | 42          | 0     | 0.79   |              
Page Request | firefox | issue3448 | 1            | 2           | -0    | -28.57 |              
Rendering    | firefox | issue1810 | 6120         | 2210        | 3910  | 63.89  | faster       
Rendering    | firefox | issue2909 | 20797        | 4255        | 16543 | 79.54  | faster       
Rendering    | firefox | issue3448 | 1809         | 1165        | 644   | 35.59  |              

Firefox nightly 25a1:

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0
-- Grouped By stat, browser, pdf -- 
stat         | browser        | pdf       | Baseline(ms) | Current(ms) | +/-  | %     | Result(P<.05)
-----------------------------------------------------------------------------------------------------
Overall      | ffNightly | issue1810 | 1944         | 1269        | 676  | 34.74 | faster       
Overall      | ffNightly | issue2909 | 6738         | 4523        | 2215 | 32.87 | faster       
Overall      | ffNightly | issue3448 | 681          | 466         | 215  | 31.57 | faster       
Page Request | ffNightly | issue1810 | 2            | 3           | -0   | -6.67 |              
Page Request | ffNightly | issue2909 | 42           | 42          | -0   | -0.13 |              
Page Request | ffNightly | issue3448 | 2            | 2           | -0   | -10.0 |              
Rendering    | ffNightly | issue1810 | 1941         | 1266        | 676  | 34.8  | faster       
Rendering    | ffNightly | issue2909 | 6695         | 4480        | 2215 | 33.08 | faster       
Rendering    | ffNightly | issue3448 | 679          | 464         | 215  | 31.67 | faster       

Chrome 28:

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36
-- Grouped By stat, browser, pdf -- 
stat         | browser  | pdf       | Baseline(ms) | Current(ms) | +/- | %     | Result(P<.05)
----------------------------------------------------------------------------------------------
Overall      | chrome28 | issue1810 | 1499         | 1502        | -4  | -0.24 |              
Overall      | chrome28 | issue2909 | 5313         | 5327        | -13 | -0.25 |              
Overall      | chrome28 | issue3448 | 501          | 490         | 11  | 2.15  |              
Page Request | chrome28 | issue1810 | 3            | 3           | 0   | 0.0   |              
Page Request | chrome28 | issue2909 | 47           | 44          | 3   | 6.82  |              
Page Request | chrome28 | issue3448 | 4            | 3           | 1   | 33.33 |              
Rendering    | chrome28 | issue1810 | 1494         | 1497        | -4  | -0.25 |              
Rendering    | chrome28 | issue2909 | 5260         | 5281        | -20 | -0.39 |              
Rendering    | chrome28 | issue3448 | 496          | 486         | 10  | 1.98  |              

[Snuffleupagus]

/botio test

[pdfjsbot]

From: Bot.io (Windows)

---

Received

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

Live output at: http://107.22.172.223:8877/9296ad355478fb9/output.txt

[pdfjsbot]

From: Bot.io (Windows)

---

Failed

Full output at http://107.22.172.223:8877/9296ad355478fb9/output.txt

Total script time: 21.74 mins

• Font tests: Passed
• Unit tests: Passed
• Regression tests: FAILED

Image differences available at: http://107.22.172.223:8877/9296ad355478fb9/reftest-analyzer.xhtml#web=eq.log

[yurydelendik]

/botio-linux test

[pdfjsbot]

From: Bot.io (Linux)

---

Received

Command cmd_test from @yurydelendik received. Current queue size: 2

Live output at: http://107.21.233.14:8877/7c1620962e5048c/output.txt

[pdfjsbot]

From: Bot.io (Linux)

---

Success

Full output at http://107.21.233.14:8877/7c1620962e5048c/output.txt

Total script time: 23.65 mins

• Font tests: Passed
• Unit tests: Passed
• Regression tests: Passed

[yurydelendik]

https://bugzilla.mozilla.org/show_bug.cgi?id=893038 might help with the inlining

Could you tell which build of Nightly you used for benchmark?

[fkaelberer]

Could you tell which build of Nightly you used for benchmark?

It should be a recent linux build from 1 or 2 days ago. I would have to check at home to tell you if it was 32 or 64 bits, if that was your question.
Actually it is not the Nightly build that had strange timings, but rather the 24a2, which needed up to 20 seconds per page of #2909.

https://bugzilla.mozilla.org/show_bug.cgi?id=893038 might help with the inlining

Thank you, I'll have a look at that.

[fkaelberer]

How come the windows test failed?

[Snuffleupagus]

How come the windows test failed?

That's an intermittent failure that's been around for some time, so you can safely ignore this.

[timvandermeij]

@Snuffleupagus Could you generate a preview for this PR? I'd like to test it. :)

[Snuffleupagus]

/botio-windows preview

[pdfjsbot]

From: Bot.io (Windows)

---

Received

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

Live output at: http://107.22.172.223:8877/68ae65f146b5cc6/output.txt

[pdfjsbot]

From: Bot.io (Windows)

---

Success

Full output at http://107.22.172.223:8877/68ae65f146b5cc6/output.txt

Total script time: 0.31 mins

Published

• Viewer: http://107.22.172.223:8877/68ae65f146b5cc6/web/viewer.html
• Extension: http://107.22.172.223:8877/68ae65f146b5cc6/extensions/firefox/pdf.js.xpi
• Extension (AMO): http://107.22.172.223:8877/68ae65f146b5cc6/extensions/firefox/pdf.js.amo.xpi

[timvandermeij]

It's indeed faster. On Windows 7 x64, Firefox 22 and PDF.js 0.8.396, the loading time for the PDF in #2909 went down from approx. 19 seconds for the first two pages to approx. 14 seconds for the first two pages. The PDF in #3448 also appears to be a bit faster, but it was already very fast (approx. 1 second) for me, so hard to say. Definitely a great optimization here :)

[yurydelendik]

28% faster for me for lastest Nigthly. Thanks

[yurydelendik]

JPX is using the same decoder, could you look if your optimization will do the magic there as well?

[fkaelberer]

JPX is using the same decoder, could you look if your optimization will do the magic there as well?

I guess it would work, but I think that the arithmetic coder is not the bottleneck there. At least not in the examples of #3181, #2790, and #268 (http://simonster.com/S2.pdf).

[yurydelendik]

JPX is using the same decoder, could you look if your optimization will do the magic there as well?

I guess it would work, but I think that the arithmetic coder is not the bottleneck there

Yeah, but 28% improvement is a good improvement if we can get it on JPX decoding. See also a discussion at https://bugzilla.mozilla.org/show_bug.cgi?id=847389 for other JPX bottlenecks. One of them index variable "type", "casting" it to int (e.g. a[i >> 0] v.s. a[i]) might improve the performance a little.

[fkaelberer]

@yurydelendik As your references to Bugzilla suggest, Firefox does seem to have a problem with inlining/not inlining methods. I was optimizing some code for the jpx decoder in various ways, but surprisingly, the only thing that really helped was extracting some often-called code to its own method, see #3554. Was something preventing the compilers from doing their work?

[fkaelberer]

JPX is using the same decoder, could you look if your optimization will do the magic there as well?

No it does not work here, its slower. I just tried.
In JBIG2, the context array was a sparse array length of length 1<<15, and the sparse accesses could be accelerated by using typed arrays.
In JPX, the contexts are either single objects (which would be converted to an array of length 1) or arrays of length 17. Not much to gain here.

[yurydelendik]

I was optimizing some code for the jpx decoder in various ways, but surprisingly, the only thing that really helped was extracting some often-called code to its own method, see #3554. Was something preventing the compilers from doing their work?

I really appreciate you looking into this. I was talking to js engine guy. Many things can go wrong and prevent compiler doing inlining. In the past I used https://addons.mozilla.org/en-US/firefox/addon/jit-inspector/?src=api to check what's going on with ion compiler. Thanks to checking those stuff for us.