On Friday 12 September 2003 08:10, Ingo Klöcker wrote:
> On Thursday 11 September 2003 14:29, JES wrote:
> > Hi,
> > Does anyone know how I can find out what part is using so much
> > memory ? I can only see that kmail is using a lot :
> >   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU
> > COMMAND 8849 edwin     15   0  424M 303M 11200 R     1,1 60,5  
> > 0:16 0 kmail
>
> Please check which functions cause the excessive memory usage. To
> do this simply use KMail as you use it every day and have a look at
> KMail's memory usage from time to time.
>
> I noticed dramatic increases in memory usage when I searched
> multiple folders for certain messages.

I need to do some profiling but there are a couple things that are 
concerning me, and that I'm looking into.

The first is in kmsearchpattern, previously there was a 
matches( DwString ) method that was called by kmfoldersearch. This 
method used mmap so that for searching except for complete message 
and body searching only the message headers ever had to be loaded 
from disk.

Now this method isn't used anymore and it means that for all searches 
the complete message has to be loaded from disk and parsed.

Another thing that is concerning me is something that isn't new at 
all, but for some reason it didn't really occur to me how much of a 
problem it is until recently. And that is the number of virtual 
methods in the message classes. I count 56 in KMMsgBase alone, and 
there are more in KMMsgInfo and KMMessage. This is bad news for a 
global search that opens all folders this means for my some 400,000 
messages, at least 100MB of ram will be needed.

Now part of the problem here is that searching now opens all folders 
searched, where as previously only one folder was kept open at a 
time. But rather than try to minimize the number of open folders, I 
would prefer to make opening folders cheaper memory wise by fixing 
the problem with the message classes being so heavy. This will also 
have the additional benefit of making filtering cheaper memory wise 
also, since filtering keeps all folders accessed open.

I'm working on addressing both of these issues as part of the imap 
client side filtering and asynchronous filtering patch. But these 
kind of issues are meaning that it's taking me longer to finish than 
I had initially expected. Hopefully I'll have something ready in 
another 10 days, but it would be nice for me if no big changes are 
made to the message, and filtering classes in the next 10 days.

Don.
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail