[Bug?] Performance issues

[Petemir]

Hello! First of all, thanks for the great app! It's a really nice contribution to OSS and, having recently migrated to macos from linux, I find it essential. Now, to my question...

I feel that the search may be working a bit slow on my computer, and I'm not sure why. Usually, there's a few seconds delay from when I type something to when the corresponding result appears. This becomes a bit problematic if I want to press "enter" to open the corresponding result, as the result has already changed when the "enter" is effectively processed.

It also produces a weird behaviour when trying to do e.g. math calculations. If I were really impatient (and bad at math 😄), I would have concluded that 5*3 is 20.

I searched through the issues but couldn't find anything related there, so I have the feeling this may be only happening on my computer. Is this actually the normal performance? Is there anything I could help to debug the issue further?

Thanks once again! Cheers.

[ospfranco]

hmm no, this shouldn't be anywhere this slow, which version are you using? You can check it out when you open the app, then do ⌘ + comma and go to the about page

How did you install the app, it can be the latest versions are not updated on brew, you can download the latest release from the releases page

[ospfranco]

You seem to have a lot binaries that are added to the search by defaut, I recently re-did fuzzy searching which was too slow with a lot of entries. You should try the latest versions.

[Petemir]

Sorry, I forgot the platform info:

Hardware: Macbook Air M2, 16GB RAM, 512GB SDD OS: macos Sonoma 14.6.1

SOL Version: 2.1.103 Installation method: brew

[ospfranco]

Ok, then you just have too many entries on the search index, which is rebuilt on each key press, which paths/binaries have you added to your system? This libxxx entries?

[Petemir]

Yes, I did come across the issue where search paths were discussed, but I didn't add any, it appears empty as default.

[ospfranco]

no, I don't mean in-app those paths are only used when searching for files. I mean in your normal macos folders. The app works by scanning /Applications folders and indexing the files there. If you have extra files somehow then all of them get added to the root search index and it will be too slow.

[Petemir]

Thanks for clarifying, now I got it. I didn't add there anything that is not an app, but certainly there are some file-hungry apps, i.e.

sudo find /Applications -type d -mindepth 1 -maxdepth 1 -exec sh -c 'echo "$(find "{}" -type f | wc -l)" : {}' \; | sort -h

(redacted, but to make a point:)

    8236 : /Applications/TeX
    8696 : /Applications/Adobe Acrobat DC
   10670 : /Applications/Inkscape.app
   19063 : /Applications/GIMP.app
   19693 : /Applications/Microsoft OneNote.app
   20788 : /Applications/XAMPP
   27694 : /Applications/Microsoft PowerPoint.app
   32367 : /Applications/Numbers.app
   33021 : /Applications/Pages.app
   34520 : /Applications/Keynote.app
   35215 : /Applications/Microsoft Excel.app
   37655 : /Applications/GarageBand.app
   46129 : /Applications/Microsoft Word.app
   52367 : /Applications/Microsoft Outlook.app
   55492 : /Applications/AnythingLLM.app
   56760 : /Applications/iMovie.app
  108630 : /Applications/Xcode.app

OK then, in that case, not much to do I guess :) (i.e., duplicate of #113 ). Thanks for the quick reply!

[ospfranco]

I guess it comes from TeX and XAMPP, if you want you can try to tackle this yourself by modifying:

https://github.com/ospfranco/sol/blob/main/macos/sol-macOS/lib/ApplicationSearcher.swift#L19

I mostly use Sol for my own use case, such edge cases didn't bother to cover

[Petemir]

Well, I don't have time right now to setup the full node/ruby environment at the moment so I just played a bit on the Swift Playground on XCode. It seems that changing

https://github.com/ospfranco/sol/blob/a2cf82d240bce3e04275f5ca08a911d4b140c75e/macos/sol-macOS/lib/ApplicationSearcher.swift#L57

to

if (resourceValues.isExecutable ?? false) && (resourceValues.isApplication ?? false) {

already reduces the url list list from ~33k to ~160 :). Additionally, XCode stopped crashing because of lack of RAM when executing the modified file. I am not sure why that resourceKey was being fetched because it doesn't seem to be used, but it was convenient for my case.

btw, regarding the following line:

https://github.com/ospfranco/sol/blob/a2cf82d240bce3e04275f5ca08a911d4b140c75e/macos/sol-macOS/lib/ApplicationSearcher.swift#L87

The Swift contentsOfDirectory documentation says

mask Options for the enumeration. Because this method performs only shallow enumerations, options that prevent descending into subdirectories or packages are not allowed; the only supported option is skipsHiddenFiles.

Therefore, I am not sure FileManager.DirectoryEnumerationOptions.skipsPackageDescendants has any effect.

I won't be able to do the full dev setup in the short-term to test the whole compiled app, but if you want/care I could make a PR just modifying the first line (i.e., adding resourceValues.isApplication), or both if you prefer. Obviously, feel free to directly apply the modifications yourself, if it suits you and you agree with them :) .

Thanks once again!

[ospfranco]

I think there was an use case of someone that needed the file scanning, but I can modify it for now and see what happens :)

[ospfranco]

I've been trying to create a release but it doesn't seem to work atm, probably apple having issues with their servers. I'll do a release later or tomorrow.

[Petemir]

No problem at all, just knowing that this will be fixed soon is enough 💯 .

[ospfranco]

Should be released now, give latest version a try

[Petemir]

Works perfectly! It feels like a totally different app :).

Thank you very much!