[Kde-pim] Problem with KDE PIM Enterprise

[Ingo Klöcker]

On Sunday 28 October 2007, Till Adam wrote:
> On Sunday 28 October 2007 14:07:38 Ingo Klöcker wrote:
> > On Tuesday 23 October 2007, Ingo Klöcker wrote:
> > > Hi,
> > >
> > > I'm having serious problems with KMail from the enterprise
> > > branch. When I start KMail then KMail starts 160 or more kio_file
> > > processes. This kills my brand new Core 2 Duo system for more
> > > than 15 minutes. With the KDE 3.5 branch version (from yesterday)
> > > this problem does not occur. With this version KMail starts
> > > within seconds.
> > >
> > > Attached are three snapshots of KSysGuard:
> > > - using the precompiled kdepim provided with OpenSUSE 10.3
> > > - using self-built enterprise version of kdepim from today
> > > - using self-built KDE 3.5 branch version of kdepim from
> > > yesterday
> > >
> > > The dent in the load graph approx. 5 minutes after the start of
> > > KMail is caused by 2 'kontact --iconify' instances that freeze
> > > KMail until they are killed. The KDE 3.5 branch version starts a
> > > single Kontact instance that does not freeze KMail.
> > >
> > > As far as I can see those kio_file process all access a .../cur
> > > folder (of which I have 200+).
> >
> > I have identified the revision in which this regression was
> > introduced: =====
> > SVN commit 669156 by tilladam:
> >
> > Implement a size column in the shared folder tree class and in
> > kmail. Add the ability to use a configurable color for the
> > folder name and size when it is close to a configurable quota
> > threshold (provided the folder has quota info in the first
> > place). Implement size retrieval for mbox and maildir storage.
> > =====
> >
> > Apparently, all maildir folders are queried simultaneously on
> > startup of KMail. Please use a job queue for this instead.
>
> That would be a bug indeed, it's not supposed to do that, and doesn't
> here, from what I can tell. I'll have a look.

Well, you use KDirSize::dirSizeJob() but all those jobs seem to be 
started at the same time instead of being queued.


> > Alternatively, have a look at how the values for the "Total column"
> > (i.e. the number of messages in a folder) are determined. The last
> > time I enabled the Total column the numbers were determined one
> > after the other. Moreover, they were only determined if they were
> > actually needed, i.e. if one had enabled the column.
>
> The last bit should already be the case, the size should not be
> calculated if the size column is hidden, and on request only when
> needed by a tooltip.

The problem is the line
  fti->setFolderSize( fti->folder()->storage()->folderSize() );
in KMFolderTree::slotFolderExpanded() which causes the folder size to be 
calculated.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20071028/04131113/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/