807162 - [meta] IonMonkey: Fix PdfJs performance (octane benchmark)

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Nicolas B. Pierron [:nbp]]

Analyze why PdfJS benchmark is slow and fix issues in separated bugs.

Comment 1

[Nicolas B. Pierron [:nbp]]

Attachment: Move size-based aborts after the usecount.

This patch move the size based rejection of IonCompilation after the use count, such as we don't get abort noise before attempting an Ion Compilation.

Comment 2

[Hannes Verschore [:h4writer]]

The bounds failures are due to: pdfjs.js:17068, function getToken().

headerString[i] is read before tested if (i < count). Every time (i >= count) we don't use the output of headerString[i], but since it is wrongly scripted the output is requested and observable. As a result we fail the bounds. Fixing this is only possible by adjusting the source code. I cannot see a way to fix this in the engine. The potential loss is 400 points on 12000. So not that big either.

Comment 3

[Hannes Verschore [:h4writer]]

(In reply to Hannes Verschore [:h4writer] from comment #2)
> The bounds failures are due to: pdfjs.js:17068, function getToken().
This will get fixed in bug 932800

Comment 4

[Enrique]

Maybe related to this bug,

I noticed that any pdf document (example http://www.lua.org/doc/jucs05.pdf) consumes lot of CPU after initial rendering. The more I zoom-out the document (more visible pages), the more CPU it takes. For example with a 100% Zoom, it takes 15% of CPU in an Intel Core-Duo. When a zoom-out at 25% it takes up to 52%. When I switch to another tab, CPU ussage goes down to 0.0. 
Looks like it's re-rendering in an infinite loop whenever the PDF window is visible.

As reference, Google Chrome takes 0.0% once the initial rendering has been done.

More info:
'top' indicates the CPU is being consumed by the main thread ("firefox" on Linux).

Comment 5

[Till Schneidereit [:till]]

(In reply to Enrique from comment #4)
> Maybe related to this bug,

Certainly not related, no: this bug is about how fast part of what PDF.js does is, not about whether it does any superfluous work. What you describe sounds like an issue with PDF.js, not SpiderMonkey.

If you could open a bug in the PDF.js bug tracker, I'm sure the team would appreciate it: https://github.com/mozilla/pdf.js/issues/