103444 - improve mailnews performance avoiding the frequent pref calls (and string prefs, copies and allocations)

Status: RESOLVED WONTFIX

(SeaMonkey :: MailNews: Message Display, defect)

Description

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

improve performance avoiding the frequent pref calls and string copies

I'll get you a log of all the char prefs we get and copy on startup, when 
doing -mail.

Comment 1

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

Attachment: pref log

Comment 2

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

Attachment: a start of what I want to do

Comment 3

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

Attachment: hack for prefapi.c

Comment 4

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

I want to add non-scriptable methods GetTypeConst()

instead of going through prefs (and that hashtable lookup), and allocating and 
copying the string, I want to fix it so we can return const ** to the type.

add a nsCString (mType) to nsMsgIncomingServer.

NS_IMETHODIMP nsMsgIncomingServer = GetTypeConst(const char **type)
{
  *type = mType.get();
}

we'll have to fix GetType / SetType to poke mType

then, find the C++ callers of GetType and fix them to use GetTypeConst().

can't do js, since GetTypeConst() will not be scriptable.

same goes for directory, redirector type, userName, hostName, anything that is 
showing up on the logs.

Comment 5

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

while it won't save us string allocations and string copies, we're also doing a
lot of bool and int pref calling when we could cache the values in the server.

here comes a new diff and a new log.

Comment 6

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

Attachment: log from doing -mail

Comment 7

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

Attachment: hack to prefapi.c

Comment 8

[Cavin Song]

I did some measurement tests and from the results I don't think the prefs calls
play a major role in deteriorating performance.

Test Data (in milliseconds):

1. Calling GetDisplayStartupPage(&yesNo) which returns member variable value.

  GetDisplayStartupPage: Time needed for 1-1000 calls is 0
  GetDisplayStartupPage: Time needed for 1001-2000 calls is 0
  GetDisplayStartupPage: Time needed for 2001-3000 calls is 0
  GetDisplayStartupPage: Time needed for 3001-4000 calls is 0
  GetDisplayStartupPage: Time needed for 4001-5000 calls is 0

2. Calling GetType(getter_Copies(type)) which gets value from prefs.

  GetType(): Time needed for 1-1000 calls is 30
  GetType(): Time needed for 1001-2000 calls 30
  GetType(): Time needed for 2001-3000 calls is 30
  GetType(): Time needed for 3001-4000 calls is 30
  GetType(): Time needed for 4001-5000 calls is 30

Here is test code I wrote:
#if 1   // Timing test
  PRIntervalTime startTime,currTime;
  nsXPIDLCString type;
  PRBool yesNo;
  int i, j, k, from, to;
  for (k=1; k<=2; k++)
    for (i=1; i<=5; i++)
    {
      to = i * 1000;
      from = (i-1)*1000+1;
      startTime = PR_IntervalNow();
      for (j=from; j<=to; j++)
      {
        if (k == 1)
          rv = GetType(getter_Copies(type));
        else
          rv = GetDisplayStartupPage(&yesNo);
      }
      currTime = PR_IntervalNow();
      if (k == 1)
        printf("GetType(): Time needed for %d-%d calls is %d\n", from, to, 
               (long)PR_IntervalToMilliseconds(currTime-startTime));
      else
        printf("GetDisplayStartupPage: Time needed for %d-%d calls is %d\n",
               from, to, (long)PR_IntervalToMilliseconds(currTime-startTime));
    }
#endif

Comment 9

[scottputterman]

moving to future based on Cavin's results which show this wouldn't save much time.

Comment 10

[Wayne Mery (:wsmwk)]

wontfix based on measurements in comment 8 ?

Comment 11

[Magnus Melin [:mkmelin]]

Might as well close. New bugs are cheap and analysis from 2001 is getting very old. Plus it does seem it was no problem/solution, according to the numbers.