Version: (using KDE KDE 3.4.2) Installed from: Unlisted Binary Package OS: Linux Perhaps it is a wish list, but the effect is so large that I think it is properly a performance bug... My bookmark list has about six thousand bookmarks in several dozen folders and subfolders; the 'bookmarks.xml' is 1.5MB large. When I delete a bookmark or move it even within the same folder 'keditbookmarks' chews up several seconds of (user) CPU time (it is actual CPU time, not mere wait time, I checked) on a fairly fast system. It feels like that the time taken to delete or move a bookmark is proportional to the total number of bookmarks. Looking at the screen it seems like the entire bookmark tree is being redisplayed, as the display looks ''partially redrawn'' for most of those several seconds.
Speaking with some people on '#KDE-devel', their impression is that most of the time is taken by writing out the whole bookmarks file in XML more than by redisplay, which is also an issue.
Well 6000 bookmarks is probably a little insane. Profiling seemed to indicate that elimanating a few calls to KBookmark::address() could make a difference, as a lot of time was spend in it. I even have a few ideas how to improve it, but I currently don't have the time to work on it.
It might be enough to allow choosing explicit saves, where saving the bookmark list does not take place after every single operation. I don't mind waiting a bit every now and then when I save the list. But several seconds of pause on every change is pretty appalling.
Isn't a duplicate of bug 59401?
«Isn't a duplicate of bug 59401?» Yes, it looks like it is a duplicate, so linked them, even if bug 59401 was initially misdiagnosed as a broadcast-update issue. It is instead very clearly a save-data slowness issue. I am marking this as a duplicate and then I'll add some new information to it. *** This bug has been marked as a duplicate of bug 59401 ***