On Tuesday 05 February 2013 09:01:21 Mark wrote: > The thing i'm puzzling most with right now is how i can optimize > UDSEntry. Internally it's a hash and that very visible in profiling. > Also in KFileItem one part that i find a little strange is this line: > http://quickgit.kde.org/?p=kdelibs.git&a=blob&h=6667a90ee9e1d57488bb7e085167 > 658f2fb9f172&hb=533b48c610319f3ad67e6f5f0cbb65028b009b8f&f=kio%2Fkio%2Fkfile > item.cpp (line 290). That line is causing a chain of performance penalties. > Which is very odd because i'm testing this benchmark with 500.000 > files, not directories. It should not even end up in that if.
You're reading the if() wrong. When used via KDirLister, KFileItem is constructed with a base URL and a UDSEntry. The base URL is the url of the directory (so urlIsDirectory is true) and the UDSEntry contains the filename (from the kioslave). So m_url.addPath(m_strName) is done, in order to construct the full URL to the file. The thing is, KDirListerCache keeps all KFileItems in cache, for faster directory browsing (of already-visited dirs). So if you want to reduce memory usage, implement a LRU mechanism in KDirListerCache, to throw out the oldest unused dirs. Would help in real life -- not really in your testcase though (one huge directory). > Or am i reading massif wrong..? Massif shows me that line for KUrl > data consumption.. One of the highest memory consumptions. Well, the kfileitems are kept around, and each kfileitem has a KUrl in it, which is kept too. I'm surprised that this would be the main use of memory though. Well, it's the biggest field in KFileItem, indeed. We could of course construct this KUrl on demand (so that the "directory" part of it is shared amongst all KFileItems, via QString's implicit sharing)... This would shift the balance towards "more CPU, less memory", so one would have to check the performance impact of such a change. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by BlueSystems and KDAB to work on KDE Frameworks _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
