Closed
Bug 593543
Opened 14 years ago
Closed 9 years ago
Extremely slow typing in the location bar / high CPU. fragmentation?
Categories
(Toolkit :: Places, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: neilio, Unassigned)
Details
(Keywords: perf, regression)
Attachments
(2 files)
I'm seeing extremely slow typing and very high CPU usage in the trunk nightlies that I haven't noticed in earlier builds. I've tried vacuuming my places.sqlite database but that doesn't seem to have fixed the issue.
Also, if I quit and restart Firefox, the slowness/cpu issue disappears. It seems to be more easily reproducible after waking from sleep as well.
Shark profile attached - hope this is useful.
![]() |
||
Comment 1•14 years ago
|
||
Neil, did you forget to attach the profile?
Reporter | ||
Comment 2•14 years ago
|
||
![]() |
||
Comment 3•14 years ago
|
||
So... 60% under stepStmt, but more interesting 10% in kernel space messing with semaphores. Hard to tell what's going on, since this looks like a profile that was done against a build with no frame pointers, so Shark more or less fails to deal.
Comment 4•14 years ago
|
||
Possibly related to bug 570975? Can't possibly tell without better stacks though.
Component: History: Global → Places
Product: Core → Toolkit
QA Contact: history.global → places
![]() |
||
Comment 5•14 years ago
|
||
Better stacks basically involve a custom build....
Neil, I assume this isn't reproducible enough to easily find the regression range?
Keywords: regression
Comment 6•14 years ago
|
||
I thought we were shipping symbols in our mac builds (although, maybe not 64-bit ones) for this very reason. I know I used to be able to use a nightly to get good shark profiles. Did this change?
![]() |
||
Comment 7•14 years ago
|
||
We still ship symbols. But we're now using -fomit-frame-pointer on Mac, and shark can't walk the stack without a frame pointer, apparently. So you get samples and the samples are blamed to the right functions, and the "heavy" part of the profile should look ok (as long as you don't open the twisties), but anything that depends on the exact stacks is broken.
![]() |
||
Comment 8•14 years ago
|
||
Note that you _do_ get useful stacks in the above profile for sqlite, presumably because it overrides the global optimization flags.
Comment 9•14 years ago
|
||
(In reply to comment #7)
> We still ship symbols. But we're now using -fomit-frame-pointer on Mac, and
> shark can't walk the stack without a frame pointer, apparently. So you get
> samples and the samples are blamed to the right functions, and the "heavy" part
> of the profile should look ok (as long as you don't open the twisties), but
> anything that depends on the exact stacks is broken.
Ugh. That makes things really not useful :(
(In reply to comment #8)
> Note that you _do_ get useful stacks in the above profile for sqlite,
> presumably because it overrides the global optimization flags.
I don't have a mac, so I can't actually open that profile and see. What does the full SQLite stack look like? (And yeah, we compile SQLite with -O2)
![]() |
||
Comment 10•14 years ago
|
||
> Ugh. That makes things really not useful :(
jlebar is working on some patches to -fno-omit-frame-pointer at least in shark builds....
> What does the full SQLite stack look like?
This attachment has it.... not the most readable thing in the world; I should see if I can set up something to convert shark export stuff into HTML+twisties.
All the percentages here are percentages of sqlite step time.
Comment 11•14 years ago
|
||
(In reply to comment #10)
> This attachment has it.... not the most readable thing in the world; I should
> see if I can set up something to convert shark export stuff into HTML+twisties.
It's OK, I'm used to reading it like this and I've gotten pretty good.
I was looking for basicFunctionHelper, but that doesn't show up too high here. You might have a case of some serious fragmentation here.
Updated•10 years ago
|
Keywords: perf
Summary: Extremely slow typing in the location bar / high CPU → Extremely slow typing in the location bar / high CPU. fragmentation?
Comment 12•9 years ago
|
||
Unfortunately this doesn't have enough information to act on it. Moreover the code changed much from when this was files, so any conclusion may not apply anymore.
Feel free to file a new bug against current Aurora / Nightly if this bug is still visible there.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•