Further clarity re: "Creating hotkeys via double-colon labels performs better than using the Hotkey command"

[20170201225639]

The doc (both v1 and v2) state on the page for the Hotkey command

> (1) Creating hotkeys via double-colon labels performs better than using the Hotkey command because (2) the hotkeys can all be enabled as a batch when the script starts (rather than one by one). Therefore, it is best to use this command to create only those hotkeys whose key names are not until after the script has started running. One such case is when a script's hotkeys for various actions are configurable via an INI file.


The way in which the bolded sentence is worded clearly states (2) to be ONE way in which (1) is true. It also invites the inference that (2) is the ONLY way in which (1) is true (i.e. that there's no other performance advantage possessed by dynamic over static hotkeys), but it doesn't explicitly say whether this is so.

I wonder if the doc could be clearer on this question. Is the only performance penalty of dynamic hotkeys incurred at the stage of hotkey creation? So that, while it takes longer to set these up, once a dynamic hotkey HAS come into existence, it is indistinguishable (esp. performance wise) from one defined statically?

(I ask because I'd very much like to create *all* my hotkeys dynamically (I want to set up a system whereby different classes "register" their own set of needed hotkeys using static initializers (alternatively, to keep hotkey definitions in json files, to be read at script start, as in VSCode/Sublime, so the key mappings are kept separate from the code itself)). I consider the flexibility thus gained to be easily worth whatever delay incurred at the start of the script, but maybe not, if the hotkeys set up in this way also has inferior subsequent performance.)

[swagfag]

the former is faster, since u got c++ parsing the script at compile time
the latter is slower, since u got ahk code having to be ran by the interpreter, ure passing strings around, possibly concatenating them
for example, on my computer a script with 20k A-Z 3char hotstring permutations loads instantly if theyre hardcoded, and in about 8secs if theyre not. thats at least a couple of orders of magnitude slower

once defined though, there shouldnt be a penalty for invoking a hotkey/string's function. doesnt matter what was used to declare it

[20170201225639]

Thanks swagfag for the explanation and for doing the test to verify. It's interesting how big the difference in loading time is between those 2 cases. What I'm still slightly confused about is, presumably for most ordinary use cases which don't come anywhere near the 20K hotstring scenario, the difference between the 2 approaches must be negligible when it comes to loading time. If loading time is indeed the only difference performance-wise between double-colon definitions and Hotkey commands, then for most ordinary use cases the performance differences between two approaches are overall basically negligible (maybe one approach takes an extra 0.5 sec to load, who cares). Why then does the Doc go out of its way to advise against using Hotkey commands everywhere on performance grounds when the difference is neglible for most ordinary (non-stress-testing) contexts? I just hope hotkeys/hotstrings created by the Hotkey command aren't somehow less performant/reliable past the initial loading stage.

[swagfag]

for hotstring scripts it might not be negligible. imagine if u had 100k autocompletions / spelling corrections. in one case the script fires immediately, in the other nothing appears to happen for at least a minute or so. that's why it should probably be mentioned

[20170201225639]

I see swagfag, that does make sense! I also have thousands of hotstring-equivalents, but implemented by InputHook, since I want the ability to show autosuggestion pop-ups (like when you are typing on a mobile phone, or when you use an IME/code editor) and use e.g. Tab key to "commit". So I never noticed any delay that may be due to huge number of native hotstring definitions.

2021_0930_1023_12 (Curly Budgie).gif (57.19 KiB) Viewed 2684 times

(Now if only I knew of an easy way to make this script masquerade as an genuine IME so can get access to genuine caret positions in non-native apps ... )

[lexikos]

Although I didn't write it, I believe the documentation is referring to the cost of Hotkey::ManifestAllHotkeysHotstringsHooks(), not interpreter overhead. Enabling or disabling a hotkey requires reevaluating all hotkeys, due to the complicated inter-dependencies between some hotkeys. If you create hotkeys with the Hotkey command, this process will be repeated for each hotkey.

Unless you Suspend hotkeys first.

Why then does the Doc go out of its way to advise against using Hotkey commands everywhere on performance grounds when the difference is neglible for most ordinary (non-stress-testing) contexts?

It does not. The premise of this question is wrong on several points.

I just hope hotkeys/hotstrings created by the Hotkey command aren't somehow less performant/reliable past the initial loading stage.

Of course it does not. It is referring to the performance of creation; or more precisely, how long the Hotkey command takes to complete.

Also, it has nothing to do with hotstrings.

[kczx3]

Unless you Suspend hotkeys first.

Some might read that as that they should start suspending hotkeys before making several calls to Hotkey. Would you say that is a recommendation? Or only in extreme cases of thousands of hotkeys?

[lexikos]

I have not made a recommendation. Suspending hotkeys before making several calls to Hotkey should allow them to complete faster. The difference in performance can be quantified, but the importance it has is subjective. I haven't found it to matter to me, but I generally don't use the Hotkey command/function that way.

[kczx3]

Cool

[20170201225639]

Although I didn't write it, I believe the documentation is referring to the cost of Hotkey::ManifestAllHotkeysHotstringsHooks(), not interpreter overhead. Enabling or disabling a hotkey requires reevaluating all hotkeys, due to the complicated inter-dependencies between some hotkeys. If you create hotkeys with the Hotkey command, this process will be repeated for each hotkey.

Unless you Suspend hotkeys first.

Thank you for the informative reply, lexicos.

Why then does the Doc go out of its way to advise against using Hotkey commands everywhere on performance grounds when the difference is neglible for most ordinary (non-stress-testing) contexts?

It does not. The premise of this question is wrong on several points.

I worded it badly. It could easily be read as 'advise against (using Hotkey commands) everywhere', but I intended 'advise against (using Hotkey commands everywhere)' (on account of the doc saying "best to use this command to create only those hotkeys whose key names are not known until after the script has started running", which was the sentence that initially triggered my alarm because I was precisely hoping to use the command to create *all* hotkeys). Scope ambiguity

[mikeblas]

I also have thousands of hotstring-equivalents, but implemented by InputHook,

Are you able to share your script? It would be useful for testing and analysis.

`ManifestAllHotkeysHotstringsHooks()` does do lots of looping, and adds and removes hooks and hot key registrations with Windows APIs. But it should be possible to improve it to minimize that work when it's being called again in order to adjust the list of registered hotkeys and hooks.