593543 - Extremely slow typing in the location bar / high CPU. fragmentation?

Status: RESOLVED INCOMPLETE

(Toolkit :: Places, defect)

Description

[Neil Lee [:neilio]]

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

[Boris Zbarsky [:bzbarsky]]

Neil, did you forget to attach the profile?

Comment 2

[Neil Lee [:neilio]]

Attachment: Shark profile

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

[Shawn Wilsher :sdwilsh]

Possibly related to bug 570975?  Can't possibly tell without better stacks though.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Better stacks basically involve a custom build....

Neil, I assume this isn't reproducible enough to easily find the regression range?

Comment 6

[Shawn Wilsher :sdwilsh]

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

[Boris Zbarsky [:bzbarsky]]

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

[Boris Zbarsky [:bzbarsky]]

Note that you _do_ get useful stacks in the above profile for sqlite, presumably because it overrides the global optimization flags.

Comment 9

[Shawn Wilsher :sdwilsh]

(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

[Boris Zbarsky [:bzbarsky]]

Attachment: sqlite data

> 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

[Shawn Wilsher :sdwilsh]

(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.

Comment 12

[Marco Bonardo [:mak]]

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.