Version: 1.5.1 (using KDE 3.1.1) Compiler: gcc version 3.2.3 OS: SunOS (sun4u) release 5.8 I am using KDE and kmail on Solaris 8. In our environment, we manage our users with NIS. I have found for as long as I have been using KDE/kmail (since about KDE 1.5) that performance was slow when switching between local folders of emails. The contents of those folders didn't seem to influence how long the switch time was. For example, switching to a folder of 10 or 1000 messages was irrelevant. Switch times of 10-15 seconds were common. I did an investigation and found that kmail was blocked in initgroups() for most of the time during the switch. In fact, switching folders seemed to result in three calls to initgroups() and each can take a couple of seconds. I found this reference online: http://mail.cc.umanitoba.ca/source/ Apparently the initgroups() implementation on Solaris doesn't perform well when using NIS. An implementation which is faster is available from this page which can be used with LD_PRELOAD. Sure enough, that fixed the problem and I can now switch between folders quickly by preloading this alternate implementation of initgroups(). It would be ideal if Sun fixed their implementation but I have some doubts that this will happen. Failing that, could kmail be changed to call this alternate implementation of initgroups() when it is built for Solaris so the LD_PRELOAD hack can be removed? The usability of kmail has increased substantially for me and I wonder how many others may be dealing with slow performance but not know how to fix it.
kmail doesn't call initgroups itself. Do you happen to know through what call we call initgroups (e.g. setting a breakpoint in that function when running kmail)?
Here is a stack trace: 15906: kmail ----------------- lwp# 1 / thread# 1 -------------------- fd840d40 initgroups (3b0338, 1e, fd77ef98, fd78b1d8, fd785908, fd77efb8) + 4 fe4a04fc KProcess::start(KProcess::RunMode, KProcess::Communication) (ffbed598, 4, 0, fd891a28, 0, 0) + 6d0 00160f70 KMFolder::updateIndexStreamPtr(bool) (3ac5f8, 1, fd8bffd0, 2e35d0, 2dee90, ffffffff) + 1a4 001fc9f8 KMFolderMaildir::close(bool) (3ac5f8, 3c, 1fc8ac, 2dee90, ffbed758, ffbed768) + 14c 001240ac KMHeaders::setFolder(KMFolder*, bool) (4500a8, 3ba558, 0, 123354, 2d8918, 0) + d58 000b901c KMMainWin::folderSelected(KMFolder*, bool) (2efe48, 3ba558, 0, fe73b4e8, fe8722a0, 4de6e8) + 108 000afcd8 KMMainWin::qt_invoke(int, QUObject*) (2efe48, 4c, ffbeda28, afc28, 2d1994, 0) + b0 fde6387c QObject::activate_signal(QConnectionList*, QUObject*) (480750, 420758, ffbeda28, 2c, 495070, ffffffff) + 15c 001160e8 KMFolderTree::folderSelected(KMFolder*) (480750, ffbeda28, 1, 2ceafc, 6d61696c, 696d6170) + 64 00112834 KMFolderTree::doFolderSelected(QListViewItem*) (480750, 4da410, 1163f4, fd841c44, 0, 0) + 144 001163f8 KMFolderTree::qt_invoke(int, QUObject*) (480750, 6c, ffbedc28, 11634c, 2d7a70, 0) + ac fde637c8 QObject::activate_signal(QConnectionList*, QUObject*) (480750, 31f6e0, ffbedc28, 9, 4828f0, 48079c) + a8 fe10998c QListView::currentChanged(QListViewItem*) (480750, ffbedc28, 488ad8, 4, 12, 0) + 7c fdf22bfc QListView::setCurrentItem(QListViewItem*) (480750, 4da410, 2ceb08, fe2a06b4, 2430, ff0000) + 164 fdf1f3ec QListView::contentsMousePressEventEx(QMouseEvent*) (480750, ffbede98, 488ad8, ffbedd90, fd69e650, 57af28) + 34c fe7342a8 KListView::contentsMousePressEvent(QMouseEvent*) (480750, ffbede98, 0, ffbedef0, a8, 58) + 264 fdf46d10 QScrollView::viewportMousePressEvent(QMouseEvent*) (480750, ffbee480, 2ce9f4, 4811e0, 0, ffbedff8) + b4 fdf465bc QScrollView::eventFilter(QObject*, QEvent*) (1, 31f550, ffbee480, 11c0af, 41348243, 0) + 10c fdf1eae8 QListView::eventFilter(QObject*, QEvent*) (480750, 31f550, ffbee480, 2fd4f8, 54c430, 0) + 58 00115e64 KMFolderTree::eventFilter(QObject*, QEvent*) (480750, 31f550, ffbee480, 115e48, 16, 20) + 1c fde61560 QObject::activate_filters(QEvent*) (0, ffbee480, ffffffff, fd841c44, 6400, 0) + 5c fde614a0 QObject::event(QEvent*) (31f550, ffbee480, fdf61168, 0, 81010100, ff0000) + c0 fde92e84 QWidget::event(QEvent*) (31f550, ffbee480, 2cc690, fdf60d64, fd69e650, 57af28) + 18 fde12258 QApplication::internalNotify(QObject*, QEvent*) (0, 31f550, ffbee480, 6230, 9d, 2f678c) + d8 fde11920 QApplication::notify(QObject*, QEvent*) (0, 31f550, ffbee480, bfffffff, ff35dd60, 7fffffff) + 168 fe46d0a0 KApplication::notify(QObject*, QEvent*) (ffbeeac0, 31f550, ffbee480, 2cfc54, ffbeeac0, fe29e612) + 118 fddbb500 QETWidget::translateMouseEvent(_XEvent const*) (40000000, bfffffff, ffbee480, 2e3074, 54c430, 0) + 9f8 fddb89dc QApplication::x11ProcessEvent(_XEvent*) (ffbeeac0, ffbee730, 2e3074, 0, 7fffffff, bfffffff) + 500 fddcd12c QEventLoop::processEvents(unsigned) (fe268848, 19, 30a688, 4, 6400, ff3c6348) + 790 fde24ba0 QEventLoop::enterLoop() (31acf0, fde24b28, fe2916d0, 62dc, 0, 5) + 78 fde24a70 QEventLoop::exec() (30a688, 1, fe2916d0, fde24a2c, 84, 2e3660) + 44 fde12488 QApplication::exec() (ffbeeac0, ffbee960, 2e3000, 1, 0, ffbee8d0) + 14 00213ca4 main (ffbeeab0, ffbeea58, ffbeec54, 2e307c, 0, 0) + 9a0 000994b4 _start (0, 0, 0, 0, 0, 0) + 5c ----------------- lwp# 2 / thread# 2 -------------------- fd75ed38 _dynamiclwps (0, 0, 0, 0, 0, 0) ----------------- lwp# 3 -------------------------------- fd75a728 _lwp_start (0, 0, 0, 0, 0, 0) -------------------------- thread# 3 -------------------- fd75ddbc _reap_wait (fd7829e0, 20520, 0, fd77e000, 0, 0) + 38 fd75db14 _reaper (fd77ee30, fd784740, fd7829e0, fd77ee08, 1, fe401000) + 38 fd76b728 _thread_start (0, 0, 0, 0, 0, 0) + 40 So, yes, it does look like this isn't in fact a kmail problem but something which KProcess just does. I guess I have misattributed this defect to kmail when it is more of a core KDE issue. Perhaps I will try my LD_PRELOAD have with more than kmail. It may improve performance elsewhere also. However, the behaviour I see with kmail when I switch folders is kmail seems to fork three child processes, one after the other. In each child process, they perform a call to initgroups() (through KProcess). So, one switch results in three forks() and the initgroups() calls in the three child processes. Sorry for the lack of a stack trace in the initial bug report.
Hmm there are three consecutive calls to 'utime' in KMFolderIndex::updateIndexStreamPtr in kmfolderindex.cpp But I don't see what they could be related to KProcess.
See also bug 131507.
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.