User Agent: Steps to reproduce: 1. about:memory 2. Ctrl-R Actual results: 1., 2. need about two seconds to complete. Expected results: 1, 2. complete in less than 0.5 s. Built from http://hg.mozilla.org/mozilla-central/rev/866b2b1793cd
How long does the first load of the page take?
Component: General → about:memory
Product: Firefox → Toolkit
QA Contact: general → about.memory
(In reply to aceman from comment #1) > How long does the first load of the page take? Both loads seem to take the same time, about two seconds.
Huh, it's slow for me too. Do you want to bisect this, Stefan?
Keywords: regression, regressionwindow-wanted
(In reply to Justin Lebar [:jlebar] from comment #3) > Do you want to bisect this, Stefan? I'll try to.
mozregression helps make the process much faster. https://github.com/harthur/mozregression
2011-10-12-03-10-18-mozilla-central is the first bad nightly
Did mozregression give you a pushlog range?
(In reply to Justin Lebar [:jlebar] from comment #7) > Did mozregression give you a pushlog range? No. I've checked the nightlies manually.
about:buildconfig will tell you what revision the build was made from. It would be helpful to have the revisions of the last good and first bad nightly.
Last good nightly: 2011-10-11 First bad nightly: 2011-10-12 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ccea01542d0b&tochange=e0ae39a3298e
Thanks. Maybe it's http://hg.mozilla.org/mozilla-central/rev/8e85383d821e.
I can't reproduce this. It is fast for me (0.5s), tested on 2011-10-11 and 2011-10-13. I am on 32bit.
It's fast for me on Windows, which is a data point in favor of the /procs/smaps stuff.
Or against, depending on how you look at it ;-)
Yes, I think it's bug 693101. We're parsing /proc/maps once for every entry in /proc/smaps.
Assignee: nobody → justin.lebar+bug
Summary: about:memory takes two seconds to complete on load/reload → MapsMemoryReporter parses /proc/self/maps once for every entry in /proc/smaps, making about:memory slow to load
Created attachment 566913 [details] [diff] [review] Patch v1
Attachment #566913 - Flags: review?(khuey)
Comment on attachment 566913 [details] [diff] [review] Patch v1 Review of attachment 566913 [details] [diff] [review]: ----------------------------------------------------------------- I probably should have caught this the first time around :-/ ::: xpcom/base/MapsMemoryReporter.cpp @@ +181,5 @@ > }; > > NS_IMPL_THREADSAFE_ISUPPORTS1(MapsReporter, nsIMemoryMultiReporter) > > +MapsReporter::MapsReporter() : mSearchedForLibxul(false) Nit, put the initializer on the next line?
Attachment #566913 - Flags: review?(khuey) → review+
> I probably should have caught this the first time around :-/ And I shouldn't have made this mistake! Anyway, inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/ec435f2a6082
Thanks for filing this bug, Stefan, and thanks for helping, Aceman, Stefan, and Thomas.
I didn't help much. I actually do not see the bug. Is it 64-bit only?
You don't see this bug because your machine doesn't have /proc/smaps. (FWIW, I never would have seen this bug if you hadn't moved it into toolkit/about:memory.)
Hey, after the bug you refer to, I already have smaps (at least /proc/self/smaps), I enabled it in the kernel. I do get "Resident Set Size (RSS) Breakdown" sections in about:memory. So, other idea?
> So, other idea? Maybe your idea of "slow" is slower than the reporter's. :)
That usually is, I am quite patient:) However, I said it takes me 0.5s, the reporter says 2s. It may depend on CPU and size of smaps. I could have small smaps, but doubt I have better CPu than you (as you see the slowness too).
(In reply to aceman from comment #24) > It may depend on CPU and size of smaps. Here I get > wc smaps 8124 26264 277402 smaps
I have: 4245 13520 131671 smaps In /proc/pid/smaps of the running Firefox 10. Am I looking into the right file?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in before you can comment on or make changes to this bug.