Sluggish Mail Application (Apple Mail & Thunderbird) Using KM Macros

Greetings KM Collective:

In the two e-mail applications that I use – Mac Mail and Thunderbird – I have KM scripts to move selected e-mail(s) to various subfolders.

The speed of these scripts sometimes becomes ridiculously sluggish (ala, it’s “faster” to manually move the document than execute the script).

Is there anything that I can do to make these menu scripts run faster, or more efficiently?

Thank you,

Paul

[Moderator's Note:  When the OP uses the term "script" he actually means KM macro]

You will need to post your scripts and macros in order for us to be of much help.

See

My apologies and palm-to-forehead "doh!"

I've attached the scripts that are "sluggish", though the two for Mac Mail are particularly sluggish.

Thank you,

Paul
Mail Group Macros 20170901.kmmacros (4.0 KB)
Thunderbird Group Macros 20170901.kmmacros (4.2 KB)

I haven't looked at your macro/scripts yet, but let me ask you this:
Have you tested the scripts using Script Editor? If so, are they sluggish there?

Hello JMTX!

I’m afraid venturing into Script Editor is beyond my skills (which is why I lean on Keyboard Maestro!).

I don’t know how to export KM macros to look at them under a Script Editor microscope, but have received some amazingly insightful “under the hood” (script-based) tips in the past.

Thank you,

PPS

I think this was a misunderstanding and @JMichaelTX thought you were speaking of AppleScripts. (AppleScripts are better edited in Script Editor than in KM Editor.)

But your uploaded macros don't contain any AppleScripts, as far as I’ve seen.

That is – probably – because you used the term “script” where you meant ‘KM macro’. Normally, on this forum, “script” means ‘AppleScript’, ‘JavaScript’, etc. while a KM macro is usually called “macro”.


I’ve tested one of your macros for Mail (“Move To Read CalArts 20161002”), replacing the destination mailbox with an actual mailbox on my computer, and it works fine and fast.

Maybe you were trying to move the mail to the mailbox of a different account, and the mail had a huge attachment. And thus the sluggishness?

1 Like

Hello, Tom!

Nice to hear from you, as always, and – as always – thank you for the clarification.

Indeed, one of the macros (sorry for the nomenclature ignorance) is moving mail between mail accounts.

The irony is that in Mac Mail, there is an option to repeat the previous move (“Move to XXXX Again…”), and – assuming it’s the same destination (the different account/folder) – said keyboard shortcut is almost instantaneous.

That’s what confuses me: my macro is asking the same thing as the above (assuming it’s the same destination), but hangs for a spell.

Thank you for your patience,

Paul

So, we are essentially speaking of a Mail issue, not a KM issue, right?

Just to make some things clear:

When Mail is sending a message (including any attachments) to another account it…

  • moves the message locally and
  • sends it to the the server of the other account (aka sync)

The first one is fast, the latter one not so, depending on the message/attachment size. Now, it's up to the Mail.app when it will report success: 1) Once the message has locally been moved, or 2) once the message has been successfully transferred to the other server. The latter would be more sincere.

So, what I imagine is happening, is that the first time you move/send the message Mail will wait with the success message until the data is really transferred. Then, when you select "Move again" it gives you a premature success message even while the transfer (server sync) is not yet finished.

When you're doing it with the macro you always Move the message (never Move Again), so you will of course always get the "slower" success message (but the more sincere).

Just my theory :wink:

Try it out in Mail.app with Move and Move Again while having the Activity window open (⌥⌘0).


PS (40 minutes later):

In the meantime I've tested it with two different messages with two different large attachments (roughly same size), and it's more or less as I've imagined:

Moving the first one: It disappears immediately from the message list, but the Activity window shows that the transfer is still going on (several minutes)

Moving the second message (with Move Again): Exactly as the first one.

So, my result is not consistent with yours in that both messages showed immediate success (= disappearing from the list) but took equally long to be transferred actually.

Maybe you hadn't the Activity window open and you mistook the disappearance of the message from the list as finished transfer?

Hello Tom,

As usual: I wasn’t clear…

My KM Macro is to move a message to a subfolder in a different account.

Now, let’s say I have done that MANUALLY (drag…), and then go to the Move Again menu, the move is almost instantaneously.

Whereas, if I tried to do the move with the KM Macro, it takes a while.

I just did both of the above with the Activity window open, and there was no noticeable difference.

My conclusion here is that because KM is working “around” native Mail processes (ala background folder synchronization), at falls at the end of the queue?

The KM macro is still faster than dragging; the problem becomes if I move around the message window and have a message different than the one I intended to move when the macro “kicks in” – then I have to undo.

Thank you,

Paul

LOL, it may well be me who is misunderstanding simple stuff :wink:

Now, let's say I have done that MANUALLY (drag…), and then go to the Move Again menu, the move is almost instantaneously.

As said, this may be question of what you define as the completion of the mission: when the message disappears from the list, or when the transfer is really finished (-> Activity window). Of course in case of small messages w/o attachments both is the same. (But we're not talking of this, I guess.)

Whereas, if I tried to do the move with the KM Macro, it takes a while.

Your macro (at least the one I tried) just selects "Move to" from Mail's menu.

I just did both of the above with the Activity window open, and there was no noticeable difference.

So, both actions take the same amount of time, right? (According to the Activity window). This seems correct and sane to me.

So, there's something I don't get. Or, do you mean, only when the Activity window is open there is no time difference, but when it isn't open there is a difference?

My conclusion here is that because KM is working "around" native Mail processes (ala background folder synchronization), at falls at the end of the queue?

Nope. You are just GUI-scripting Mail via KM, that is you are making KM selecting menu items in Mail. It is the same as doing it manually. I would understand what you mean if we were talking about AppleScript where you can "directly" access some Mail functions, bypassing the GUI. But this is not the case here.

So… I'm a bit clueless now…

As for “clueless”, that makes two of us.

It makes no sense why what is ostensibly the identical action (based on your description of how KM macros function) takes a different duration to effect contingent on the input source.

No difference in the duration, by the way, between having the Activity window open or closed.

Perhaps it’s “somebody’s” way of telling me to be patient…

Try this script here (not by me).

It moves a message without resorting to the GUI. Just to see if it makes any difference.

  1. Copy the script text from your web browser (A, C)
  2. Paste it (V) into a new window in Script Editor (/Applications/Utilities/Script Editor.app)
  3. In Mail, select your test message; open the Activity window
  4. Back to Script Editor, run the script (R)
  5. Select the destination account/mailbox and hit Return

Compared to selecting “Move” from Mail’s menu (or using your KM macro) does this run faster?

Thank you, Tom.

Mr. Zeitler’s script works, but then a window opens with ALL of my e-mail folders (hundreds) to select from, and upon finally FINDING the one I’m seeking (the sort order seems arbitrary), I would say that the move of the selected message is considerably slower.

Additionally, it is worthwhile to note that as this is a not GUI move, methinks it’s not registered as something one can undo, correct (at least, this was my experience)?

Onward. And not to spend any more time worrying about this millisecond of a problem unless there’s an obvious fix.

Best,

Paul