Summary: | run kio_http_cache_cleaner when user is idle | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kio | Reporter: | Michiel de Bruijne <m.debruijne> |
Component: | http | Assignee: | kdelibs bugs <kdelibs-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ahartmetz, chrislb, oliver.henshaw |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Michiel de Bruijne
2005-11-30 04:57:51 UTC
I am the Debian user who is mentioned at the end of bug 130862 ("kio_http_cache_cleaner starts every few minutes and causes extreme disk I/O or thrashing"). I was recently digging through http_cache_cleaner.cpp again and was wondering if there is a good justification for its complexity. In my version of http_cache_cleaner.cpp it looks like readEntry()'s purpose is to ensure that all files in the cache are at the correct cache version, that they include a URL, and that their "creation date" is less than KProtocolManager::maxCacheAge seconds old. I feel like the first two checks properly belong to the code that directly writes and reads the cache entries (http.cc ?), and the last check could go off filesystem time, avoiding the fopen() in readEntry() entirely. If that is really feasible in the larger design then kio_http_cache_cleaner could execute in just a few seconds even on systems with large (> 1 GB) cache sizes. *** Bug 205931 has been marked as a duplicate of this bug. *** I have fixed this in trunk. The most important (most used) data about cache entries is duplicated in one big central file so we can avoid reading hundreds or thousands of small files. Filesystem metadata (which is orders of magnitude faster to read) is used for a consistency check. Seems to work well. If it's gone, you've solved the for me worst bug in KDE4. Thank you very much! Can this be ported to 4.4.1? Yeah, I'm planning to backport this. |