I ticked the preference that Chris mentioned. It’s interesting info. Watching the progress, it seems that “update index” takes as long as “index”. I don’t know if that’s good or bad – had never observed it before.
@tom I suppose I could cut back more on indexing, but then that defeats that purpose of LB somewhat. I don’t index anything on other volumes, though, since even before Sierra that proved to slow performance. Good to know (sort of) that it seems to be a Sierra issue. I’ll try to remember to activate LB then go to something else for 90 seconds when I boot.
I am running Sierra and I am not experiencing a delay; however, I run very thin on all macs re: files, media, etc., so I don't think I have as much to index as some of y'all.
You're right -- and when I watched each index rule one-by-one, I think I might have found my problem -- it's the indexing for ~/Documents. It's a 109GB folder!
The updating takes a very long time, building the cache (the step at the end of indexing) also takes a long time, and the index picks up a lot of things that I would never use LB to search for. I need to break down the Documents index into discrete indices for the folders/file types that I actually need. The LB default for what's included in the Documents index is overly inclusive for my needs.
By the way -- by watching each index update in the index panel I notice that panel triggered by "Automatically Show and Hide Indexing Progress" only opens when a particular index takes more than some threshold time. Maybe a second? Not sure. So that panel is not necessarily a good indicator for how long indexing takes end-to-end. Just how long the longer index updates take.
If you are already indexing only the stuff you need (and not much more), then yes, cutting back the index would defeat the purpose of LB.
But in my case it was different. I noticed – for example – that all the time I was indexing a folder with ~500 subfolders and a total of ~17K html files; this folder is a very rarely accessed read-only archive of html docs, and when I’m searching something in it (3 times/year) I use Spotlight either way, so --> absolutely braindead to have those 17K files in LB’s index.
Together with some other completely unnecessarily indexed folders, the exclusions apparently added up enough to reduce the indexing time very noticeably, but without hampering the usefulness of LB at all.
Thanks for the hint, but no network volumes. For testing I removed Mounted Volumes completely from the index, but in principle it doesn’t affect the unresponsiveness issue, maybe it reduced the unresponsive time a little bit.
Thanks for the interesting information.
I just double-checked the behavior with a couple of system reboots and LB’s “Automatically show and hide Indexing Progress” enabled. What is happening is exactly this:
Computer boots up.
Pretty early I get the first LaunchBar Indexing window popping up. I do nothing.
Computer continues to boot up, menu bar gets populated, apps are starting up, etc.
During that time I get 2 to 3 times more the LaunchBar Indexing window. I’m still waiting.
After ~2 minutes, when everything seems to have done its boot work, I finally call LB with my hotkey.
The LB window comes up instantaneously, I type something in, the window is unresponsive (in the latest tests for about 5s), then the previously typed text gets actually typed in, and LB does its job.
During the 5 seconds no LaunchBar Indexing window is coming up.
Can you confirm that you don’t have that delay at all? (I’m asking because if your index is very slim, the delay might only be 1 or 2s.)
PS:
At this very moment, shortly after the last reboot, my index folder (~/Library/Caches/at.obdev.LaunchBar/Index) has 4.4MB.
FWIW, I am observing this (or similar) behavior on my MBA running macOS 10.11.6 when I wake from sleep, and launch LB. The LB prompt appears on launch, and does not respond to my typing for 10-15 sec.
I don't remember when this started happening, but it seems like it was very recent, within the month, or less. I will have to investigate to determine what has changed within the last month.
OTOH, when I wake my MBP-15R (also running macOS 10.11.6) from sleep, there is NO delay when LB is launched.
Of course, my MBP is much more powerful than my MBA. I don't know whether or not this is a factor.
But the big difference with my MBA and what you guys are reporting, is that it is running El Capitan (not Sierra).
That’s interesting, because it could mean that the delay was introduced with a certain version of LB that by coincidence happened to be released around the same time as Sierra.
With the difference that with El Capitan the delay happens after wake from sleep, while with Sierra it happens after reboot. (With Sierra I don’t have any delay after wake from sleep.) — But not on all machines apparently.
Yes, over here my MBA, mid-2012 with 10.12.3, has no LB delay on wake-from-sleep. Just have LB delays after reboot from Apple menu (same user), logout / login (different user), or launch after shutdown-then-boot.
The LB delays happen the first time I use LB after one of those events. LB is one of my login items, but even if I reboot and wait an hour, the first time I invoke LB I get a delay.
FWIW, my index is 21.5 MB. Maybe @Tom's theory that the delay has something to do with a recent LB version -- or even the recent versions' interaction with Apple security patches that were applied to both 10.11.x and 10.12.x.
You are right, the delay also happens after logout/login, not only after system boot.
I noticed that 2.5MB of my 4.4MB index folder (=58%) belong to a “frameworkCache” file, which is built when indexing Development Resources:
However, disabling the indexing of Development Resources (and thus reducing the size of the index folder to 1.9MB) did not improve the delay.
Further I have 39.6MB in ~/Library/Caches/at.obdev.LaunchBar/Temporary Items/com.apple.Safari/History.db. Disabling the indexing of the Safari history didn’t change the delay either.
FWIW: Out of curiosity I added the entire ~/Library folder to the index (“Any Item”). This blew up the index folder from 4.4MB to 93.3MB and increased the unresponsive delay from 5 seconds to 2 minutes.
Note: This was for testing only. For normal usage this is complete madness, and not necessary. If you want to add the Library folder, it is normally sufficient to limit the index to “Folders” (not “Any Item”) and you should exclude large parts of the Library (e.g. Caches, Containers, and many more) via “Skip Subfolders”.
@Tom, I'm responding to a post you made in the Script Debugger forum because we have a better LB thread here.
@Tom, thanks for sharing. As always, your insights into LB are amazing and very helpful.
So, I was trying to follow your approach for executing a script via LB.
In the case of processing a Finder selection, I wonder if we really need to send the selection to LB first?
For example, if I select one or more files/folders in the Finder, then activate LB, all I need todo is find the script (by typing the assigned keys, or just key characters in the name), and the press RETURN.
In my case I wanted to execute the script @Finder Create @Symlink or @Alias of Selected Items in Choose Folder @Tool @AS.scpt
So I selected the Finder items, activated LB, typed "@sym" which immediately found the script, then RETURN.
But I'm probably missing something critical in your workflow.
Your thoughts?
If you have a script that already gets the Finder selection by itself, then you don’t need to “send” it.
A typical example for that would be an AS with…
tell application "Finder" to set theItems to selection as alias list
But otherwise the “Sending” is very handy because it provides the argument(s) for any script:
For example in a Perl script you can grab the arguments (= the items sent to LB) from @ARGV:
for (@ARGV){
say "$_";
}
or in Bash from $@:
for ARG in "$@"; do
echo "$ARG"
done
Also very useful for running scripts on text selections in any editor, since you can “send” the text to the script without having to bother with the clipboard.
For example in AS by using the handle_string handler:
on handle_string(_string)
return [{title:"1 string passed"}, {title:_string}]
end handle_string
See here for more details.
And of course you can send not only Finder items or selected text, but also something from LaunchBar itself. For example a file/folder you have selected in LB’s file browser, or the result from another action, etc.
PS:
To make it more clear, this is what you send with the “Instant Send” key:
