From kdepim-users Mon May 21 20:21:01 2007 From: Ingo =?iso-8859-1?q?Kl=F6cker?= Date: Mon, 21 May 2007 20:21:01 +0000 To: kdepim-users Subject: Re: [kdepim-users] KMail + IMAP painfully slow [trace info] Message-Id: <200705212221.03130 () erwin ! ingo-kloecker ! de> X-MARC-Message: https://marc.info/?l=kdepim-users&m=117977893227413 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0158424599==" --===============0158424599== Content-type: multipart/signed; boundary=nextPart14938112.oIrSpcJUau; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-transfer-encoding: 7bit --nextPart14938112.oIrSpcJUau Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 17 May 2007 07:40, Ross Boylan wrote: > 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. [snip] > 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=3D0xa8034e8) 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=3D0xa8034e8) at > widgets/qlistview.cpp:3922 > #1 0xb721c7b9 in QListViewItem::itemAbove (this=3D0xab3bf00) at > widgets/qlistview.cpp:3933 > #2 0xb721c7b9 in QListViewItem::itemAbove (this=3D0xab3beb8) at > widgets/qlistview.cpp:3933 > #3 0xb721c7b9 in QListViewItem::itemAbove (this=3D0xa2c9170) 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. QListViewItem::itemAbove() is known to be slow.=20 (http://doc.trolltech.com/3.3/qlistviewitem.html#itemAbove) > 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. This will all change with KDE 4. The Model/View approach introduced with=20 Qt 4 will make this much more sane and fast. > 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). Yeah, opening a target folder could probably be optimized. > 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? I can't give you a definitive answer. It's probably a combination of=20 historical reasons (threads were not really usable when KMail was=20 started more than 10 years ago) and the fact that the Qt mechanism is=20 really easy to use. Regards, Ingo --nextPart14938112.oIrSpcJUau Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBGUf8vGnR+RTDgudgRAhs8AKCj/GCUVWhdUPD/MDdKVeVJdGNkwwCaArav TA2kCK2FIuF0gmymvM52EXg= =Or+l -----END PGP SIGNATURE----- --nextPart14938112.oIrSpcJUau-- --===============0158424599== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KDE PIM users mailing list kdepim-users@kde.org https://mail.kde.org/mailman/listinfo/kdepim-users --===============0158424599==--