Open
Bug 807162
Opened 12 years ago
Updated 2 years ago
[meta] IonMonkey: Fix PdfJs performance (octane benchmark)
Categories
(Core :: JavaScript Engine, defect, P3)
Core
JavaScript Engine
Tracking
()
NEW
People
(Reporter: nbp, Unassigned)
References
(Depends on 7 open bugs, Blocks 1 open bug)
Details
(Keywords: meta, Whiteboard: [ion:p1])
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Analyze why PdfJS benchmark is slow and fix issues in separated bugs.
Updated•12 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Updated•12 years ago
|
Reporter | ||
Comment 1•12 years ago
|
||
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.
Updated•12 years ago
|
Whiteboard: [ion:p1]
Comment 2•12 years ago
|
||
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•11 years ago
|
||
(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
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•10 years ago
|
||
(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/
Reporter | ||
Updated•7 years ago
|
Updated•5 years ago
|
Summary: IonMonkey: Fix PdfJs performance (octane benchmark) → [meta] IonMonkey: Fix PdfJs performance (octane benchmark)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•