111976 - reduce number of mork tables we create when loading a folder

Status: RESOLVED FIXED

(MailNews Core :: Database, defect)

Description

[David :Bienvenu]

Creating mork tables is showing up in the quantify logs. There are at least two
things going on here. One is that when we're in threaded view, we get the thread
for the msg hdr what seems like dozens of times per row to figure out if there
are any unread children. Here's the relevant code:

  if (m_viewFlags & nsMsgViewFlagsType::kThreadedDisplay)
  {
    if (m_flags[aRow] & MSG_VIEW_FLAG_ISTHREAD)
    {
      nsCOMPtr <nsIMsgThread> thread;
      rv = GetThreadContainingIndex(aRow, getter_AddRefs(thread));

The obvious fix for this is to cache the most recent thread object we've been
asked for, so we'll only get it once per row.

The second operation that creates lots of thread objects is when we're in the
flat view, and we're expanding all the threads prior to sorting, we hit all the
threads again (we hit them all in the first pass where we enumerated all the
threads to find the top level threads). One possible fix for this is to expand
the threads in place when building up the ids of the top level threads. Another
possible fix is to cache the thread objects when building up the view. The third
possible (but not likely!) fix is make mork hold onto the thread object since it
has all the relevant data in memory anyway (I'm a little surprised it's not
doing this already, but it would contribute to bloat so we most likely won't do
this, even if we could). I'd rather not cache all the thread objects if I can
help it, so I'll probably implement the single thread object cache to speed up
the threaded view, and change the view construction code to go in one pass over
the threads.

Comment 1

[David :Bienvenu]

my mistake - mork does keep the table objects in memory. The changes outlined
above might still be worthwhile, but they won't have much of a measurable impact
on performance. I'll try to figure out why building the tables is so expensive.
We spend all the time doing memory allocations, but for some reason, those
allocations are slow.

Comment 2

[David :Bienvenu]

Attachment: proposed fix for caching current thread object

Comment 3

[David :Bienvenu]

I moved some common code into the CloseCachedObjects routine, and added a single
thread object cache.

Comment 4

[(not reading, please use [e-mail] instead)]

Comment on attachment 59219 [details] [diff] [review]
proposed fix for caching current thread object

sr=sspitzer

Comment 5

[Navin Gupta]

r=naving, so how often will we find the thread to be cachedThread

Comment 6

[David :Bienvenu]

we find the thread for every cell in every row we paint, so since we paint each
cell in a row before moving onto the next row, it will be very often the same
thread.

Comment 7

[Wayne Mery (:wsmwk)]

David, this one finished?

Comment 8

[David :Bienvenu]

yeah, I don't think we're going to do anything more on this.