Version: (using KDE KDE 3.2.1) OS: Linux When the option to use slocate is enabled in kfind, even trivial searches like '*.txt' in my home directory are terribly slow - much slower than when not using locate. Since the purpose of locate is to speed things up, this is strange. My suspicion is that perhaps kfind is trying to do pattern matching (which locate really can't do), so it locates _all_ files (hence slowness) and then searches for wildcards etc by itself. If this is true, I think it should rather work another way: when the option to use locate is selected, all the "advanced" features that locate can't handle are greyed out and a note appears stating that with locate you can only seach for literal substrings. At this point, anyway, the performance of kfind using locate seems unaccepatable in most cases.
Hmm yes I confirm this problem (KDE 3.2.3) Quite anoying. I do however recall that this function did at one time really do speed things up. That must have been inthe kde 3.1.x era however.
It looks like, as noted, 'locate' is run on the directory, returning all the files, and 'kfind' narrows it down from there. I'd propose, first of all, passing something like /directoryname/*filename* to 'locate' to speed up instances in which the user searches for a particular filename. This method would also need to pass the '-i' parameter to 'locate' when the 'Case sensitive search' box is clear, and possibly even when it isn't (to correct mistyped directory names). Maybe doing inventive things with regular expression searches in 'locate' would speed up some of the other options. I don't know; I haven't tried that. Other than that, it looks like slocate is in need of some updating ;)
slocate works fine. "time slocate konqueror" takes .300 sec on my system. Kfind, searching from the root directory, had to be killed after two minutes.
I'd just say I'm against limiting functionality when slocate is used because of the following: 1) As somebody already said, using slocate used to be *faster*. From a few straces, it looks like, now at least, files in the given directory are scanned regardless of whether 'use index' is selected or not. 2) If, as I said, slocate gains functionality in the form of pattern matching, it would be preferable to use said functionality in the program as close to the database as possible. 3) One case in which locate is the preferable, and possibly only, option, is to search files on a network (NFS) drive. In fact, I'd like to be able to limit users to *only* use slocate, instead of taxing fileservers and networks, and have them still be able to perform complex pattern matching. 4) kfind (probably) doesn't want to implement a full, secure, cron-able, caching utility such as slocate. Duplicating this effort would be needless.
After applying the patch in bug 77854, before which I couldn't get kfind to work at all, I can confirm that using slocate does indeed take 3-6x as long as not. My setup: I'm on a Celeron 1800, 256 MB RAM, FC1 updated to kde-3.2.3. I'm just performing a simple regexp search. Network test: Searching an NFS share on a 10mbit network, with slocate pointed at an index of the NFS share located on the share itself. 'With index' (slocate) takes 6 minutes. Without slocate takes 1 minute. Local test: Searching /usr, with slocate pointed at the local index. 'With index' takes 18 minutes. Without slocate takes 5 minutes.
On KDE 3.3 this seems to be improved somewhat. I looks like it first updates the index (to be safe?), then all subsequent searches use the index, even after exiting and restarting Kfind. I'm inclined to say this is fixed, but can anyone else confirm ?
I can't say 3.3 is improved. Using the index still takes *longer* than not, which is the point of this bug. And I'm not noticing any difference on subsequent searches (kde 3.3.2). Perhaps the index option should just be removed.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!