Closed
Bug 1138151
Opened 10 years ago
Closed 3 years ago
Scrolling on some specific pages causes Firefox to use HDD constantly and loudly
Categories
(Toolkit :: Places, defect, P3)
Toolkit
Places
Tracking
()
RESOLVED
DUPLICATE
of bug 661590
Performance Impact | low |
People
(Reporter: Virtual, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug, )
Details
(4 keywords, Whiteboard: [fxperf:p3])
Attachments
(1 file)
(deleted),
text/html
|
Details |
1. Open this URL website page - http://pubchem.ncbi.nlm.nih.gov/compound/656612?from=summary#section=Top
2. Scroll page to the bottom and next to the top a few times
3. You can clearly hear that your HDD is used loudly and constantly by Firefox
The issue doesn't occur in in:
-Chrome (Blink engine),
-Opera (Blink engine),
-Opera (Presto engine) [poor scrolling performance];
but Vivaldi (Blink engine) is also affected.
Comment 1•10 years ago
|
||
possible testcase.
Updated•10 years ago
|
Component: Untriaged → Places
Product: Firefox → Toolkit
Comment 2•10 years ago
|
||
I see lots of disk usage. But it doesn't majorly affect scroll speed, so how is this topperf?
Comment 3•10 years ago
|
||
Regression window with testcase of comment#1
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e435c9812855&tochange=cd62a8afc52e
Comment 4•10 years ago
|
||
Also occurs on http://rr-project.org/rr.html#1.0 . As soon as a page is scrolled, Nightly writes to the disk. Quickly scrolling the pages will peg the HDD constantly
Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(mak77)
Comment 5•10 years ago
|
||
the testcase is not very common, so not a priority, but still worth investigating.
Unfortunately the regression range is not really useful, too old and widespread.
Chrome is storing history for each fragment, as we do, in a similar table, so the disk load should be ideally similar.
First thing to notice from the log, we seem to read the page info twice (double calls to FetchPageInfo), likely one can be avoided (to be verified).
Then we fetch the visit id, the only reason is to notify onVisit, but it's unlikely a useful information, we we could stop notifying that and save a read.
Then we update Frecency for the url, this is expensive, we could evaluate some way to delay it so that we do only if a further visit to the same page is not seen in a timeframe (so we don't update too often).
So, there is definitely some space for improvements, but globally I think most of the churn here comes from keeping frecency updated.
Reporter | ||
Updated•8 years ago
|
Has STR: --- → yes
Keywords: nightly-community
Updated•8 years ago
|
Priority: -- → P5
Updated•8 years ago
|
Whiteboard: [qf:p1]
Updated•8 years ago
|
Whiteboard: [qf:p1] → [qf]
Updated•8 years ago
|
Whiteboard: [qf] → [qf:investigate:p1]
Reporter | ||
Comment 6•8 years ago
|
||
Maybe my profile will has some hint and speed up diagnosing & investigating this issue.
Profile: https://perfht.ml/2opHq6q
Taken with: Gecko Profiler 2.1.0
Interval: 0,01 ms
Buffer size: 900 MB
Threads: ,
Features: Stack walk + JavaScript + Task tracer
Updated•7 years ago
|
Whiteboard: [qf:investigate:p1] → [QRC][QRC_NeedAnalysis][qf:investigate:p1]
Reporter | ||
Updated•7 years ago
|
Keywords: regression
Updated•7 years ago
|
Whiteboard: [QRC][QRC_NeedAnalysis][qf:investigate:p1] → [qf:p3]
Reporter | ||
Updated•7 years ago
|
QA Contact: Virtual
Reporter | ||
Updated•6 years ago
|
status-firefox65:
--- → affected
status-firefox66:
--- → affected
status-firefox67:
--- → affected
status-firefox-esr60:
--- → affected
Comment 7•6 years ago
|
||
Since this bug is not a high priority, a regression, or a security issue, it's not necessary to track its status.
status-firefox65:
affected → ---
status-firefox66:
affected → ---
status-firefox67:
affected → ---
status-firefox-esr60:
affected → ---
QA Contact: Virtual
Updated•6 years ago
|
Severity: major → normal
Reporter | ||
Comment 8•6 years ago
|
||
It is the regression (please see the keywords), but very long standing one.
QA Contact: Virtual
Reporter | ||
Updated•5 years ago
|
Updated•5 years ago
|
Priority: P5 → P3
Reporter | ||
Updated•5 years ago
|
Comment 10•5 years ago
|
||
Google Maps is also affected when zooming and panning.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 11•3 years ago
|
||
I've simply moved my Firefox profile to a RAM disk.
The application really wants to destroy my SSD disk (and that is despite browser.cache.disk.enable=0
).
Updated•3 years ago
|
Performance Impact: --- → P3
Whiteboard: [qf:p3] [fxperf:p3] → [fxperf:p3]
Updated•3 years ago
|
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•