Description of problem: mlocate is very slow when performing a search using the '-i' arguement. Version-Release number of selected component (if applicable): mlocate-0.12-1.2 How reproducible: locate -i * Steps to Reproduce: 1. run the command, locate -i * Actual results: Slow Expected results: Fast Additional info: Compare the real times for mlocate with and without '-i': $ time mlocate -i *.mp3 real 0m5.587s user 0m4.816s sys 0m0.028s $ time mlocate *.mp3 real 0m1.749s user 0m0.556s sys 0m0.020s Compare the real times for slocate with and without '-i': $ time slocate -i *.mp3 real 0m2.187s user 0m0.176s sys 0m0.044s $ time slocate *.mp3 real 0m2.150s user 0m0.140s sys 0m0.024s
How's this? (mlocate-0.14 user times) .ogg: 0m0.144s *.ogg: 0m0.596s -i .ogg: 0m0.856s -i *.ogg: 0m1.124s From looking at the code (not trying it), case-insensitive search in slocate most likely doesn't handle UTF-8 properly. Similar speedup can be achieved by running mlocate with LC_ALL=C: (LC_ALL=C mlocate-0.14 user times) .ogg: 0m0.132s *.ogg: 0m0.280s -i .ogg: 0m0.872s -i *.ogg: 0m0.320s (Yes, LC_ALL=C mlocate -i .ogg could be sped up further, but that's IMHO not worth worrying about.) We are now frozen for FC5, I'll push this as an update after the release.
Thanks for the update. Gnome-search-tool uses the locate command to help speed up finding files so with the current version of mlocate (0.12-1.2) its performance has been noticeably degraded. I look forward to seeing mlocate-0.14 released.
mlocate-0.14-0.fc5.1 has been pushed for FC5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.