Why is the Keyboard Maestro Macro Editor Slow & Laggy?

Hi there,

Apologies if this isn't the right place to post this, but my Keyboard Maestro (which is the most recent version) macro editor interface has been slow for the past few weeks when it used to run fast.

To make it clear, the macros run smoothly and are quick, just the actual macro editor interface e.g. collapsing menus in the macro editor, scrolling up and down in the macro editor, and using the macro editor in general.

I often see a spinning loading wheel after each edit I perform. This makes editing macros quite time-consuming.

Any idea why it's suddenly slowed down? I'm running Keyboard Maestro (the most recent version too) on another macbook with worse specs and identical macros to this one, and the macro editor on that runs smoothly and quickly.

This one runs on macOS Mojave, the worse laptop runs High Sierra. Have tried reinstalling Keyboard Maestro, but still runs slowly.



I have also experienced this lately. I am using macOS 10.14.6 on a MacBookPro15,1 and Keyboard Maestro Version 9.0.4.

Glad to hear I'm not the only one.

Keyboard Maestro must be (kind of) incompatible with macOS 10.14.6 since that's what I'm using.

I just deleted some old macros and it's running a lot quicker. So everything must have been wrong on my end, not Keyboard Maestro. So I take back what I wondered about Keyboard Maestro not being very well compatible with macOS 10.14.6.

If your macro editor in Keyboard Maestro is running slowly, it might be because you have too many complicated macros.

1 Like

I also have experienced this behavior from time to time, and I believe the root cause is inherient in the KM design:

  1. KM uses a single, very large file, to store ALL macros in. I call this the "Master Macro file".
  2. Every little change you make in the KM Editor then causes an update of that Macro, which causes the entire Master Macro file to be rewritten.
  3. When the KM Editor is open for edit, it is actually processing each Action in the current Macro. And when you make a change to that Macro, it causes the KM Editor to reprocess every Action in the Macro.
    • So, for example, if you have a "Found Image" action or condition, KM is continually search maybe all your screens for that image, which is, of course, very processor intensive.
  4. If you have multiple KM Editor windows open the problem is compounded:
    • If both windows show the same macro, any change in one window causes the other window to also be updated and reprocessed
    • Even if each window is a different Macro, you now have multiple Macros being processed while the KM Editor is open.

IMO, these design issues can be solved, and should be addressed by @peternlewis.
Some of them might be easier to solve than others, and would still have a large benefit.
For example, instead of making an auto-update of ALL Macros in the Master Macro file, for every little change, wait for the user to press a "Save" button or menu.

  • IOW, do NOTHING until the user tells the KM Editor he/she is finished editing
  • Maybe one exception is to every few seconds save ONLY the current macro to a file in case of abnormal termination of the KM app (which I have never seen).
  • This is how most apps work, so why can't KM work this way?

Meanwhile, until/if some KM redesign is done, here are some workarounds:

  1. Use only one KM Window, unless absolutely necessary.
    • If you really need a second window, open a different Macro in it.
    • If you really need to have the same Macro open in both windows, DUPLICATE the macro and open the dup in the 2nd window. Delete it when finished.
  2. Try to minimize the size of your macros
    • Especially with the use of images, which are all stored as TIFF images internally, and can cause the single master Macros file to get really large.
    • Use a reference to files instead of the actual data in the file
    • This is easy to do with scripts.
  3. If you have any Macro Groups that you don't need for your production, active Macros, keep them disabled. (for example a MG for testing, like I have).
  4. If you have a large number of Macros in Macro Group (like I do for all of my "Example" macros I post), then:
    • For sure keep this MG disabled when not using
    • Export as many macros from it as possible, and delete those Macro in the MG
    • Or export as a Macro Library, and delete the originals.
  5. Found Image Actions and Conditions
    • Use the smallest possible image to find that you can.
    • Use the smallest possible region to search that you can.
  6. When NOT Using the KM Editor, either quit the app, or disable editing using the menu View > Stop Editing Macros, or click the "Edit" button at the bottom of the KM Editor window.

If anyone has other suggestions or workarounds, please post.


Have there been any other updates or ideas for this? I LOVE KM and have been using it for years now but as I'm starting to get back into adding more Macros and making them more complex, every step gets more and more tedious and laggy in the editor...

The macros themselves run great, it's just the editor that is slow, even just opening and closing it, or switching from one macro to another is painful with frequent spinning beachballs on the same machine I use to edit and process 4K videos with no problem?

I also experience it. When the editor becomes show & laggy, I would not be able too see the cursor move with Arrow keys. (I don't remember exactly, the cursor either stays where it is and stopped flashing or disappears when I use the Arrow keys to move it) I have to guess where the cursor is and starting typing or deleting.

Well as a new user I can confirm this is still an issue in KM. Seeing that the developer hasn't responded is frankly troubling... I've been using KM for about a month and started noticing it getting increasingly slower.

If what @JMichaelTX says is correct that explains the behavior I've noticed in just a short month of using KM. Initially the application was snappy, I now have consistent 2-4 second beach balls and lags between ever little edit I attempt to make.

Even just scrolling, typing, or adding a new folder in the editor causes a 2-4 second lag or a beach ball. This has easily tripled (if not quadrupled) the time required to build macros compared to when I purchased it.

Even when creating a brand new macro with no actions at all, just the act of creating a Macro folder results in a 2-4 second lag. Attempting to rename the folder results in an additional 2-4 second lag. Attempting to select the pulldown or type in the pause action results in a 2-4 second lag. Rinse and repeat, ad infinitum...

Seeing that this issue persists a year after 1st reported in this thread, and @peternlewis hasn't responded is concerning to say the least...

1 Like

What is your Mac model, RAM, etc?

Check if you have any large variables (ie variables with a huge amount of content), this macro might help find them:

I've seen the beachball when I try to edit a macro that uses a very large variable.

try disabling animations:

The original thread creator here. Not sure if it'll help anyone else's particular instance, but I found my Keyboard Maestro Editor became slow & laggy when I had lots of duplicated code/actions across many macros.

Removing duplicated code/actions and instead, packing them all into manageable chunks and using the “Execute Macro” action to re-use them whenever I needed them drastically lowered the overall number of macros I had. That made my editor back to usual speed.

No problems since then.



cool, thanks.
Might need to do some cleaning as well.

My machine's an 8 core i9 MBP with 64 GB of RAM. In terms of variables I'm not using KM to do any of this, I'm using it to perform clicks and actions in applications and plugins where shortcuts aren't available...

I realize the image recognition needs some horsepower but the editor has become exponentially slower as I've built more macros.

I'm not being even slightly hyperbolic when I say that I find myself waiting 2-4 seconds between every single edit I attempt to make in the editor. Just scrolling can cause a 2-4 second beachball, same with text entry, even just selecting or moving elements of a macro. I spent well over an hour trying to clean up a macro last night that should have taken me under 10 minutes to perform, test and complete...

Thanks Peter. I'll ry this and see if ti helps...

Thanks. Unfortunately this is a necessity for the intended purpose I bought Keybaord Maestro. I'll explain the purpose of my macros, and why the redundancy is necessary without hopefully being too longwinded...

I compose for TV full time, I have a ton of instruments and plugins I need to manage in order to finish any one specific project. Hunting for instruments, instantiating plugins for audio tasks, recalling presets; these all become bottlenecks once you have a large collection of instruments/effects you have to manage.

I've been building macros to load specific instruments, apply specific audio effect chains, and essentially make my production process as automated as possible because deadlines get shorter while and demands get higher year over year... That's an unfortunate and unavoidable reality in film/tv post production...

I use an ios app with Keyboard Meastro support built directly into it (Metagrid). This allows me to map macros to buttons, allowing me to load many of the unique instruments mentioned above. This also allows me to map frequently used audio effects, and apply the necessary effects across all busses from the click of a button.

Basically the short version is redundant code is unavoidable as each instrument/audio effect/various-other-moving-parts-of-the-process that I've mapped to Metagrid all require unique buttons that call on unique macros... So if I have a folder of 40 macros that load various instruments for me with a button press this requires me to have 40 unique macros.

As far as your comment... If what you've found is accurate this seems to suggest that the KM Editor's code could use some optimizations. I push my CPU tot the edge more or less daily on Logic, lagginess hasn't been an issue once on this machine. Frankly lagginess isn't something I've had an issue with in general in Marcos for years now...

The macros themselves run fine. But the editor is painfully slow and laggy. If the application required to build the macros themselves is bottlenecked it essentially negates some of the benefit KM should otherwise bring to the table.

Again, not being hyperbolic... Spending an hour to tweak and complete a macro that should have taken me no more than 10 minutes seems like this should be a red flag that development might want to investigate this... And if reusing the same code in multiple macros (assuming this is correct) can lead to degraded performance this seems like an even bigger red flag worth looking into. All I know is the editor was snappy on day one, has slowly become laggy, and the last week or so has gotten to the point where I'm seeing beach balls or stalls between any one single editing action... Which again includeds actions that shouldn't be a bottleneck such as entering text into the insert text or type a keystroke action.

I'll try the terminal commands @peternlewis suggested, I'm just hoping this is on developments radar... The TLDR version is you can't build working macros without a functioning macro editor... Thankfully the macros themselves run fine, but they've become pretty difficult to build in a very short time...

Appreciate everyone's input so far.. Cheers.

Why would I respond when @JMichaelTX covered a lot of it.

Also, I do not necessarily respond to forum posts. If it is an issue specific to Keyboard Maestro (not about creating a macro for a specific purpose), then feel free to email support where you will get a response.

There are many things that can cause Keyboard Maestro to be slow, and in many different ways.

The editor is designed for a relatively small set of macros (<1000), a relatively small macro file (<2MB), and relatively small macros (<20 actions). This is the typical usage. It is not designed to scale arbitrarily to unlimited size, any more than Notes is designed to write your next novel in.

Things that will slow Keyboard Maestro does significantly include long macros, very large macro files, multiple editor windows open, lots of inter-process communication (including actions that are testing and displaying conditions, especially actions that are displaying menu status and thus searching through Keyboard Maestro menus, as well as JavaScript/Web Browser actions, screen searching actions, etc).

But if you find it disturbing that I don't answer a specific forum post then you don't understand the nature of this forum - I answer support email, but I may not read or answer any specific forum posts.


I see. So degraded performance is a feature not a bug. And instead of seeing this as an area where Keyboard Maestro's editor could perhaps be improved in the future, instead these are the responsibility of the user who clearly should have known this.

Again, the simple act of creating a new macro, any macro, even one that consists of a single simple action such as typing a keystroke or inserting text results in persistent lagging and beachballs that occur every 10-15 seconds, and last for 2-4 seconds at a time. But this is a feature not a bug... Duly noted.

Based on this being known behavior, and you opting to see this a form of user error vs looking at ways to improve the editor, frankly it doesn't sound like reaching out for support will accomplish much more than a circular discussion.

Appreciate the feedback from those who replied with some strategies for dealing with this...

Something else must be going on. Keyboard Maestro is an incredibly efficient and fast running app. This is certainly not normal behaviour.

1 Like

Thanks for chiming in...

As far as I can tell this is due to KM attempting to parse the macro master list. I have roughly 360 macros I've built, most of which use some kind of image recognition. These aren't light macros per se, and I get that... However if KM's editor weren't written in such a way where every single macro is tangled up with every other macro this wouldn't be an issue.

Macros that were heavy on their own would be more resource hungry, this is something I deal with day to day in Logic. Some projects require you to scale things back by temporarily rendering things to audio. KM Editor's approach however would be equivalent to me being required to open every other Logic project and temporarily rendering everything to audio before I could resume working on the current project. I'd wind up spending more time trying to stabilize Logic than actually creating something with it...

I've found my master macro list, the single plist is 200 MB. Just attempting to preview the plist causes finder to pause for about 3-5 seconds before it can display it. Because KM lumps all macros into a single file the editor is having a hard time parsing any one macro because it's attempting to parse an insanely large file that even finder has a difficult time displaying.

This approach of wrapping everything up as one massive file would be like Premiere, Davinci, or an equivalent video editor storing each discrete project inside one single master file; and the ability to edit each discrete project hinged on the sum total of events inside that master file. The moment you had a project where scrubbing the timeline became an issue, scrubbing the timeline in every other project would also become an issue. Essentially it'd be the equivalent of that application requiring you to work on all projects at the same time.

The same could be said about any other application... Imagine if every time you edited or created a unique image photoshop's overall performance started to degrade.

As far as the (apparently intentional?) limits (<1000 macros, <20 actions, etc)... Sure, you probably wouldn't want to write a novel using notes. However notes doesn't limit you to the number of notes or characters you can write, and the user is free to write as little or as much in it as they'd like. Frankly this is like saying that an email client whose inbox can't handle more than 1000 emails, and whose replies cannot contain more than 20 unique words would be a well designed email client.

This is the developer's choice and I respect that, that said, I hit its ceiling in only a month. I personally find this to be an incredibly inefficient way to design an editor.

I’m pretty sure you don’t need so much image recognition. Are you always working with an app maximised? Would clicking at a location work?

Have you used any execute a macro actions? If not, try them. You could probably make your code much more efficient.