Trace Malloc Allocs and MaxHeap regressions from bug 752676 (Add pdf.js as an internal handler)

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
7 years ago
5 years ago

People

(Reporter: mbrubeck, Assigned: bdahl)

Tracking

(Blocks: 1 bug, {perf, regression})

Trunk
perf, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15-, firefox16-)

Details

(Whiteboard: [pdfjs-c-testing][MemShrink:P3])

(Assignee)

Updated

7 years ago
Duplicate of this bug: 761333
(Assignee)

Comment 2

7 years ago
Testing this out locally using leaktest.py on osx I get numbers all over of the place for the max heap with RSD ~2%.  Some of the smallest max heap sizes have been with the above changeset applied.  However, on average I see the max heap grow ~100KB with the pdf.js changeset.

I expect the max heap to get somewhat bigger since we're now adding two new components PdfJs.jsm and the PdfStreamConverter.js.  Also, on firstrun pdf.js has to go in and take over as the default pdf reader.

One thing we could do to lessen the memory is instead of programatically registering the stream converter we could put it back in the chrome.manifest so PdfStreamConverter isn't loaded until the first pdf is loaded.  This though would mean the stream converter is on by default which has pros/cons.

Comment 3

6 years ago
It's not clear to me what the user impact would be here (seems like a leak regression), or how commonly it would occur. Tracking nonetheless to make sure this is followed up on.
Assignee: nobody → bdahl
tracking-firefox15: ? → +

Comment 4

6 years ago
Given bug 773397, tracking for FF16's release but not FF15. Would still love to get clarification on the user impact here.
tracking-firefox15: + → -
tracking-firefox16: --- → +
(Assignee)

Comment 5

6 years ago
Alex: I must have missed your previous comment in my bugmail.  The regression doesn't seem to be a "leak".  It's just a regression in the maximum amount of memory firefox uses(~2MB more) during that test, which is then cleaned up.  I still haven't heard anything definitive if this is too much for what is happening on first run or not.

Comment 6

6 years ago
(In reply to Brendan Dahl from comment #5)
> Alex: I must have missed your previous comment in my bugmail.  The
> regression doesn't seem to be a "leak".  It's just a regression in the
> maximum amount of memory firefox uses(~2MB more) during that test, which is
> then cleaned up.  I still haven't heard anything definitive if this is too
> much for what is happening on first run or not.

OK - I've added [Snappy] to the whiteboard to get their expertise on whether or not this test is actually concerning. Also untracking for FF16 since we won't be ready to ship till FF17 at least.
tracking-firefox16: + → -
Whiteboard: [Snappy]

Updated

6 years ago
Blocks: 748930
(Assignee)

Updated

6 years ago
Whiteboard: [Snappy] → [Snappy][pdfjs-c-testing]

Comment 7

6 years ago
This might be a memshink bug, but there is nothing here for snappy.
Whiteboard: [Snappy][pdfjs-c-testing] → [pdfjs-c-testing]
Whiteboard: [pdfjs-c-testing] → [pdfjs-c-testing][MemShrink]
Whiteboard: [pdfjs-c-testing][MemShrink] → [pdfjs-c-testing][MemShrink:P3]
18 months have passed. I don't think this bug is worth keeping open.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.