Version: (using KDE KDE 3.1.2) Installed from: Unlisted Binary Package Compiler: gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) OS: Linux I've about 9000 bookmarks... When I add a new bookmark I have to way several seconds, before Konqueror returns control to me. Using Mozilla 1.3 instead the update is really fast. Can you speed up the bookmarks handling a bit, please ? Thanks.
I can confirm this too. I don't have even nearly that many bookmarks, but I too have to wait on the order of 5s for the bookmark menu to open, or if I add a bookmark and it closes, it stalls the same amount before the konqeror window is responsive again. KDE 3.1.2 gcc 2.95.3 LFS
reducing priority to wishlist as 9000 is far from a common case. due to various bug fixes bug bookmark adding is already much faster in 3.2 than it was in 3.1. Alex
I agree with the reporter and Nick. I have less than 9000 bookmarks. Adding a bookmark pretty much stops the whole desktop, for 5 seconds or so. This is my personal most hated bug in KDE. 3.2 didn't help much there. It seems you notify all running applications that are bookmark-aware of the change, in a synchronous manner. Pulling all those apps out of swap to update their bookmarks takes a lot of time. I see two solutions: 1) Signal asynchronously 2) Access bookmarks on-demand from a bookmark daemon which runs in the background. This would be the best scaling model, but also take some time.
(Sorry for spaming you) To clarify: a common scenario for me: 1) work a lot, use some programs, have 12 konsoles open, 7 konquerors, mozilla, big work programs, editors, gcc, ... 2) see 3 sites that I would like to bookmark 3) bookmark site (a) 4) bookmark site (b) 5) bookmark site (c) Here, 3) takes way longer than 4) and 5). This makes me assume that you take all those konqueror (and konsole?) instances out of swap as you push the bookmark changes to them. 3) takes about 7 seconds of freezing the whole desktop, 4) and 5) only take 1-2 seconds. Alex, maybe you don't see this freezing so much because you work with the bookmarks all the time and the bookmark-aware apps never get into swap on your machine? I just checked and I have 1000 bookmarks.
I have the same problem too. I have 3500 bookmarks and I use Konqueror 3.3.2 (KDE 3.3.2), on AthlonXP 1900+, 1GB ram. Bookmark adding/deleting/... takes 2~10 seconds.
It should be added that a big bookmark file will create a multi-column bookmark menu that covers the complete screen, which is a rather ugly view as well as a horrible experience usability-wise. See also bug 56897 + bug 58733 + bug 59401 + bug 128410 + bug 139665 for some examples, and this screenshot: http://bugs.kde.org/attachment.cgi?id=18587&action=view
*** Bug 149050 has been marked as a duplicate of this bug. ***
Please fix this really terrible bug before KDE4 leaves beta. It gives a very bad impression of KDE that its main browser is unable to handle even a moderate number of bookmarks efficiently. Konqueror is by far the slowest for bookmark editing of all modern browsers - firefox, safari, IE6, and IE7. I read some of the suggested fixes above, e.g. for a bookmark daemon and to signal other apps asynchronously. However, I don't think they would fix the problem. The bug exists even if konqueror is the only KDE app that is running. Therefore, notifying other apps is not the cause of the slow updating. It must be something else - mostly likely a bad choice of data structure for the bookmarks - one which is extremely inefficient, or typical pointless cruft in the form of unnecessary layer upon layer upon layer upon layer of method calls.
I have this bug too on Konqueror 4.1.3. It takes about 45 seconds just to display the "Properties" window of a bookmark! It's really unusable. I have about 6000 bookmarks.
*** Bug 111564 has been marked as a duplicate of this bug. ***
The problem seems to be hideously inefficient bookmark file generation, as the time taken is proportional to the number of bookmarks, but not to the number of listeners for bookmark list update events. There is some additional information in a comment to bug 111564: http://bugs.kde.org/show_bug.cgi?id=111564#c2 After some IRC discussions someone did improve a fair bit the speed with which bookmarks are saved, but it is still very too slow. I got a suggestion to look at basKet, a note-taking application, and I started using it, and it is a pretty good substitute for KEditBookmarks, and stores notes in a very different way which seems more efficient. KEditBookmarks integrates with Konqueror better than basKet (which integrates better with Firefox than Konqueror, probably that's a problem with Konqueror), but drag-n-drop works well enough.
Bug persists in kde 4.3.2
That the menu is humongous with lots of bookmarks, is not a rationale to leave this bug unfixed. On the contrary, it is a rationale to provide a better user interface for power users (I hear search interfaces are all the rage, so the interface could very well be the browser url bar, in fact firefox does this very well with over 9000 bookmarks), without necessarily taking the traditional menu out.