Page 1 of 1

LaunchBar 6 using staggering amount of memory

Posted: Sat Sep 24, 2016 6:37 pm
by asegar
I just purchased an upgrade from version 5.6.4 to 6.7.2. After a few days of Macintosh uptime (iMac with 12 GB, OS X 10.11.6) I noticed the machine was becoming sluggish, and discovered that LaunchBar memory usage had crept up to 4.6 GB!

After a restart it's down to 350 MB, but I suspect it will creep up again.

What's going on, and how can I prevent this behavior?

Re: LaunchBar 6 using staggering amount of memory

Posted: Thu Sep 29, 2016 3:40 pm
by asegar
I would appreciate a response from Objective Development technical support. What can be done to stop, or at least reduce, the memory that LaunchBar claims for itself?

I now have to quit and relaunch LaunchBar 6 every few days to prevent it swallowing up large percentages of my 12GB RAM. This never happened with earlier LaunchBar versions.

Please respond!

Re: LaunchBar 6 using staggering amount of memory

Posted: Tue Oct 11, 2016 7:27 pm
by asegar
After a few emails swapped with Objective support, there has been no resolution offered for this problem. None of the reasons that support suggested might be the cause of the staggering memory usage (e.g. cut and paste with huge clipboards) applied to my setup.

I was supplied a procedure that put LaunchBar 6 in a debugging mode and that captured debugging information in a console log. Sent the console log to Objective last week, but have received no further response. I continue to have to close and relaunch LaunchBar daily—if I don't the utility rapidly consumes multi-GB of memory.

Under the circumstances, I wish I had stayed with the earlier version of the program which never used a significant amount of memory but worked just as well as the current version.

If you are using LB 5, I suggest you think twice about upgrading.

Re: LaunchBar 6 using staggering amount of memory

Posted: Thu Oct 13, 2016 12:00 pm
by DocterD
Same issue here. :-/

Re: LaunchBar 6 using staggering amount of memory

Posted: Sun Oct 16, 2016 5:35 pm
by raistie
I got so frustrated with this stupid app that I switched to Alfred.. Best decision of my life. Couldn't even find the important files I needed

Re: LaunchBar 6 using staggering amount of memory

Posted: Tue Nov 08, 2016 1:05 am
by Riptide360
I just upgraded to the latest version of LaunchBar 6 and ran into the same issue on a Mac Pro Tower Mid 2010 Mac with 14GB of RAM. Went into the activity monitor and saw that the kernel was out of control memory wise.

Weirdly, in my case Killing Safari freed up the memory, but after reading the comments here I'm wondering if the culprit is LaunchBar. It was indexing at the time. Is this a normally RAM intensive process?

I just ordered OWC's RAM upgrade to swap out my 1GB modules with 4GB so by next week I should be up to 32GB RAM. Hopefully I don't see this problem again.

Re: LaunchBar 6 using staggering amount of memory

Posted: Thu Nov 02, 2017 6:14 pm
by Tapper
Yes, LB is using a few GB of memory on my Mac Pro 2009 with Sierra. Very disappointing as I just upgraded from version 5 a few weeks ago.

Re: LaunchBar 6 using staggering amount of memory

Posted: Mon Nov 06, 2017 6:30 pm
by SmithJones
kernel here is using 1.6 GB and LB is using 545 MB, but I have 32 GB in this Mac Pro 5,1 under Sierra 10.12.6 so I'm not too concerned...

Re: LaunchBar 6 using staggering amount of memory

Posted: Mon Nov 06, 2017 11:06 pm
by mot
Running LB here with 200–300 MB, for years.

The point is you have to exclude the stuff from your index that you don’t need. For example, it would be complete madness to index the entire Home folder, or the entire ~/Library folder, down to every file.

Make your selection. LB’s purpose is not to find anything you have on disk; you have Spotlight for that.

LB is there to give you quick access to the items you need most frequently. Up to you to tell LB what these items are.
And, this may change over time: Currently I have every item in folder A in the index because I’m actively working in it. Next month it will be folder C, and so I will index the items in folder C. Maybe I’ll leave folder A in the index, but not down to every file, just on folder level or so.

You always have the possibility to index only folders. This still allows you very quick access when navigating with LB.

Many folders you don’t have to index at all: As long as the relative root folder is in the index you can navigate along.
Let’s say you have indexed only the top level of your disk root: This will include (for example) the /usr folder. When you have to go into any subfolder of /usr, just go to /usr and then move along with the Arrow or Space key.

LB’s indexing is powerful, and it’s up to you to limit it, that is, to customize it to your needs. Don’t spend its power to index areas of your disk you never go to. (…or where you go to once in a year.)

Of course, there’s a dilemma with the default config of LB: On one side they (Obdev) are trying to show you what LB can do/find, but on the other hand the indexing scope should be small and customized to your needs.

I think they are not emphasizing enough that you have to customize your indices.

LB is not an install-it-and-it will-work-perfectly tool (like Alfred). Out of the box it will work quite OK, but if you want more (or, in the context, less memory consumption), you have to take care of it, by telling it what you want it to do.

– Tom

Edit (2017-11-14):

In the meantime, provoked by my own advice (“exclude the stuff from your index that you don’t need”), I have thinned-out my index considerably:

  • I brought down my formerly over 40000 indexed items in different folders to currently 4600 items. (This is not counting the items in the upper part of the Index window, like actions, contacts, search templates, services, etc.)
  • LB’s memory consumption now is around 170 to 200MB (not so much less)
  • Average Energy Impact went down significantly from formerly between 2.5 and 3 to now something between 1.0 and 1.5. This is pretty huge. Of course, this depends also on how frequently you use LB, but my usage pattern has certainly not changed much.
  • LB feels faster and snappier now, also over longer periods without relaunching it.

– Tom