Closed
Bug 996119
Opened 10 years ago
Closed 10 years ago
Breakdown - investigations of performance/memory usage of language detection
Categories
(Tracking Graveyard :: Firefox Operations, defect)
Tracking Graveyard
Firefox Operations
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: florian, Assigned: florian)
References
(Depends on 1 open bug)
Details
(Whiteboard: p=2 s=it-32c-31a-30b.1 [qa-])
There are several things that we need to investigate to convince ourselves that the performance and memory usage of our language detection code is reasonable. I think we should break this down in smaller parts.
Assignee | ||
Updated•10 years ago
|
Flags: firefox-backlog?
Updated•10 years ago
|
Flags: firefox-backlog? → firefox-backlog+
Comment 1•10 years ago
|
||
Following the triage meetings, this remains unassigned. Florian, would you be willing to mentor a community member through this bug? Since it's vaguely specified, you'd likely need to spend a bit of time explaining what to measure and where to find it.
Flags: needinfo?(florian)
Whiteboard: [diamond]
Comment 2•10 years ago
|
||
Nope, my mistake - No diamond status for story-breakdown bugs, sorry.
Flags: needinfo?(florian)
Whiteboard: [diamond]
Updated•10 years ago
|
Whiteboard: p=2 [qa-]
Updated•10 years ago
|
Assignee: nobody → florian
Status: NEW → ASSIGNED
Whiteboard: p=2 [qa-] → p=2 s=it-31c-30a-29b.3 [qa?]
Updated•10 years ago
|
Whiteboard: p=2 s=it-31c-30a-29b.3 [qa?] → p=2 s=it-31c-30a-29b.3 [qa-]
Updated•10 years ago
|
Whiteboard: p=2 s=it-31c-30a-29b.3 [qa-] → p=2 s=it-32c-31a-30b.1 [qa-]
Assignee | ||
Comment 3•10 years ago
|
||
We want to ensure that the performance (both startup and page load), memory usage and code size of what we ship is reasonable. I think there are 2 possible approaches here: 1. check how what we currently have performs and decide if it's acceptable; 2. compare what we have against a binary version (which we currently don't have). I think it makes sense to follow the first approach, and spend time building a working binary version only if we aren't satisfied with what we find for the asm.js version. I've filed the following bugs to investigate the various points we care about: Startup performance: Bug 1003117 - verify if the omni.ja size increase due to cld.js and cld.js.mem causes startup performance issues Page load performance: Bug 1003118 - check the impact of running language detection on page load times Memory usage: Bug 1003120 - measure resident memory use of CLD after startup Bug 1003124 - verify that CLD's memory usage doesn't grow infinitely If we aren't satisfied with the data we find in these 2 bugs, we will want to file a bug to "compare asm.js-CLD memory usage with the native CLD". I think it would be premature to file this bug now. Code size: Bug 1003125 - compare the size of the emscripten'ed CLD with the native binary
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Updated•10 years ago
|
Status: RESOLVED → VERIFIED
Updated•10 years ago
|
Updated•5 years ago
|
Product: Tracking → Tracking Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•