Closed Bug 805796 Opened 12 years ago Closed 12 years ago

"Sticky" UI for ~5 minutes while Thunderbird determines which messages to index

Categories

(Thunderbird :: Search, defect)

17 Branch
x86
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: mconley, Unassigned)

Details

(Keywords: perf)

I've been noticing this for the past few days - when I start up Thunderbird, the UI is very halt-y...it locks up for half a second, and then releases for half a second, and then locks up, and releases...

The activity manager reports that Thunderbird is determining which messages to index.

I was able to get a profile - though I'm surprised it doesn't show more red spikes:

http://people.mozilla.com/~bgirard/cleopatra/?report=cd57cbcb7858ee3ddcf0b0da6df6344a343bf06d
My officemate also has a similar problem, although his UI doesn't lock up. We've had bug 782899 where the slowness was due to strings being converted back and forth between compartments. Did we fix the root cause of this problem or not? If not, heavy indexing will still do a lot of cross-compartment calls because the indexing relies on MsgHdrToMimeMessage in the first place, which may explain the slowness. But that's a long shot, with no investigation at all to support this theory :)
Are you sure this is the right profile?   It looks pretty boring, and the only obvious things going on had nothing to do with gloda.
(In reply to Andrew Sutherland (:asuth) from comment #2)
> Are you sure this is the right profile?   It looks pretty boring, and the
> only obvious things going on had nothing to do with gloda.

I was surprised myself at the profile. I was expecting huge red spikes.

I took a profile yesterday when I hit this as well. It's quite a bit smaller, but might shed some light:

http://people.mozilla.com/~bgirard/cleopatra/?report=8f305f909c580b9fcfbcc6bd4fed82919afd3008
According to BenWa, the profiler starts wrapping if the profiling resolution is too high - so perhaps that wrapping wiped out all of the interesting stuff by the time the profile dumped. :/
The smaller profile pretty clearly fingers index_im.js, particularly in calls to ConvertMsgSnippetToPlainText in a loop that doesn't bother to break up its work.  You can probably mitigate the problem by having that loop be a for loop that "yield"s a lot in the gloda idiom.
More profiling data from this morning:

http://people.mozilla.com/~bgirard/cleopatra/?report=cbee99039f056eafb96d6377cc4015ee01516228

Florian - do you think you might get a chance to look at this?
Component: Search → Instant Messaging
Just spoke to Florian in IRC - apparently, this might actually be a problem with the profiler add-on I'm using, since the add-on SDK is throwing an exception every time it receives the notification that a new DOM document is being created, but the document has a null URL.

I've got a new copy of the profiler add-on, built with a version of the SDK that supposedly fixes that bug. I'll let y'all know tomorrow if it makes a difference.
Component: Instant Messaging → Search
Yep - this was totally the profiler slowing me down. Talk about irony. Thanks all!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.