'Re: [kdepim-users] KMail + IMAP painfully slow [trace info]'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdepim-users
Subject:    Re: [kdepim-users] KMail + IMAP painfully slow [trace info]
From:       Ross Boylan <ross () biostat ! ucsf ! edu>
Date:       2007-05-17 5:40:08
Message-ID: 200705162240.09405.ross () biostat ! ucsf ! edu
[Download RAW message or body]

I downloaded some debug symbols and attached to kmail at various times.  Here 
are the results.  I don't know if this is enough info to be helpful.

1) Moved a message to another folder:
#0  0xb7fc0410 in ?? ()
#1  0xbfafd318 in ?? ()
#2  0x08090054 in ?? ()
#3  0x0808fed0 in ?? ()
#4  0xb7930071 in select () from /lib/tls/i686/cmov/libc.so.6
#5  0xb706a2a8 in QEventLoop::processEvents (this=0x8087760, flags=4) at 
kernel/qeventloop_x11.cpp:291
#6  0xb70dd179 in QEventLoop::enterLoop (this=0x8087760) at 
kernel/qeventloop.cpp:198
#7  0xb70dcf9a in QEventLoop::exec (this=0x8087760) at 
kernel/qeventloop.cpp:145
#8  0xb70c47bf in QApplication::exec (this=0xbfafd394) at 
kernel/qapplication.cpp:2758
#9  0x0804a094 in main (argc=6332792, argv=0x0) 
at /tmp/buildd/kdepim-3.5.5.dfsg.1/./kmail/main.cpp:110
#10 0xb7880ea8 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#11 0x08049e11 in _start () at ../sysdeps/i386/elf/start.S:119

2) Entered a search string in the quick search box.  It was particularly 
suprising this stalled, since it was my main INBOX, I thought no other 
operations were happening (e.g., action described in 1 above seemed to have 
finished), and the box was already encountered and indexed.  I've put some 
comments with ##
(gdb) attach 12886
Attaching to program: /usr/bin/kmail, process 12886
[New Thread -1248798496 (LWP 12886)]
[New Thread -1288971344 (LWP 12890)]
[New Thread -1280578640 (LWP 12889)]
[New Thread -1272185936 (LWP 12888)]
[New Thread -1263793232 (LWP 12887)]
Loaded symbols for /usr/lib/libkmailprivate.so
## I had previously attached and detached for the report of item 1).
## This looks as if more than one thread was going.
## Many symbol loading messages omitted.
Loaded symbols for /usr/lib/libgcrypt.so.11
Failed to read a valid object file image from memory.
[Switching to Thread -1248798496 (LWP 12886)]
0xb721c714 in QListViewItem::itemAbove (this=0xa8034e8) at 
widgets/qlistview.cpp:3922
3922    widgets/qlistview.cpp: No such file or directory.
        in widgets/qlistview.cpp
(gdb) where
## note the next few # lines are from gdb, not me
#0  0xb721c714 in QListViewItem::itemAbove (this=0xa8034e8) at 
widgets/qlistview.cpp:3922
#1  0xb721c7b9 in QListViewItem::itemAbove (this=0xab3bf00) at 
widgets/qlistview.cpp:3933
#2  0xb721c7b9 in QListViewItem::itemAbove (this=0xab3beb8) at 
widgets/qlistview.cpp:3933
#3  0xb721c7b9 in QListViewItem::itemAbove (this=0xa2c9170) at 
widgets/qlistview.cpp:3933
## These just kept going; I stopped the output at 496.
## This looks as if itemAbove has gone crazy with recursion.
## I guess if it is following the list of items up this is possible,
## though it certainly seems undesirable.  If there is a QListViewItem for
## every message in the message, that certainly could explain some of the
## problems I've been having.  There were way more than 496 messages in the 
## box, though way less than that many items visible.

A proper solution to this would probably use a kind of database display logic, 
since that is another situation where you have tons of records and only want 
to display a few of them at a time.  Actually creating and painting the 
interface elements for every item in the box (since one might scroll there) 
is clearly prohibitive.

A bit surprisingly, given all this, the memory footprint is significant but 
not outlandish: 184k, with about 120k resident.

3) I discovered that if you click the progress bar on the bottom right you get 
detailed reports of what's going on and what's waiting.  When I moved a 
message to a new folder, this progress bar confirmed that kmail was busy 
getting information for that folder (which took forever).

4) This isn't exactly a user question, but I'm curious why kmail uses the Qt 
mechanism Ingo described rather than real threads.   Is that just to save the 
hassle of ensuring that all threads do UI updates only via the main thread?

Ross
_______________________________________________
KDE PIM users mailing list
kdepim-users@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users
[prev in list] [next in list] [prev in thread] [next in thread] 