Bug 248622

Summary:	Filelight should cache data to prevent unnecessary disk activity
Product:	[Applications] filelight	Reporter:	Amichai Rothman <amichai2>
Component:	general	Assignee:	Martin Sandsmark <martin.sandsmark>
Status:	RESOLVED FIXED
Severity:	normal	CC:	dave
Priority:	NOR
Version:	1.0
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:	http://commits.kde.org/filelight/615ea422042322da6f579678edf376f3ba7cfe16	Version Fixed In:
Attachments:	Actually use Filelight's cache Actually use the cache, updated for kdeutils 4.7.0

Description Amichai Rothman 2010-08-21 20:43:56 UTC

Version:           1.0 (using KDE 4.4.5) 
OS:                Linux

When viewing a folder with many files in it, e.g. / or /home, the scanning process can take a long time (minutes). If then one drills down into one of the subfolders, and then returns to the parent folder (using Up or Back), the folder is re-scanned, creating much more disk activity and taking a long time (again).

Reproducible: Always

Steps to Reproduce:
View the root folder on a system with many files, and possible a slow disk. Scanning takes a while. Then drill down to a subfolder, and move back up to parent folder (selecting Up).

Actual Results:  
The parent folder is re-scanned, taking a long time and creating a lot of unnecessary disk activity.

Expected Results:  
The parent directory data should be cached, so that going in and out of it takes no additional processing, resources, or time. (There is already a Rescan option if the user does want to re-scan the parent, or any other folder, so no functionality is lost)

OS: Linux (x86_64) release 2.6.32-24-generic
Compiler: cc

Comment 1 Dave Vasilevsky 2010-09-30 01:19:17 UTC

Created attachment 52094 [details]
Actually use Filelight's cache

Comment 2 Dave Vasilevsky 2010-09-30 01:20:04 UTC

Filelight does actually cache the results, but I can confirm that it's not in fact using this cache. The attached patch should fix this.

It looks like the part of ScanManager::start() that looks for a relative path within a cached directory is the problem. It is splitting the relative path "foo/bar/" into ["foo", "bar", ""], which then breaks when looking for a file with an empty name. Just declaring success on encountering an empty string should work fine.

There's a subsequent problem, that when Filelight finds a cached directory, it adds it to the cache all over again, and the resulting duplicates can eventually cause crashes. So I've added a new signal/slot specifically for cache hits, to work around this.

Comment 3 Dave Vasilevsky 2011-09-02 03:15:40 UTC

Created attachment 63296 [details]
Actually use the cache, updated for kdeutils 4.7.0

Any update on actually getting this patch into Filelight?

Comment 4 Martin Sandsmark 2013-01-04 20:50:38 UTC

Git commit a6c112e3782378e0976992574611bd1548c77fc4 by Martin T. H. Sandsmark.
Committed on 04/01/2013 at 21:49.
Pushed by sandsmark into branch 'master'.

Fix usage of cache.

Patch by Dave Vasilevsky.

M  +13   -1    src/part/scan.cpp
M  +2    -0    src/part/scan.h

http://commits.kde.org/filelight/a6c112e3782378e0976992574611bd1548c77fc4

Comment 5 Martin Sandsmark 2013-01-05 16:08:12 UTC

Git commit 615ea422042322da6f579678edf376f3ba7cfe16 by Martin T. H. Sandsmark.
Committed on 04/01/2013 at 21:49.
Pushed by sandsmark into branch 'KDE/4.10'.

Fix usage of cache.

Patch by Dave Vasilevsky.

M  +13   -1    src/part/scan.cpp
M  +2    -0    src/part/scan.h

http://commits.kde.org/filelight/615ea422042322da6f579678edf376f3ba7cfe16

Comment 6 Dave Vasilevsky 2013-01-05 22:59:08 UTC

Thanks, Martin :)

Comment 7 Martin Sandsmark 2013-01-06 19:56:11 UTC

Thanks to you, and sorry it took so long to get around to :D