Tigerlily wrote: ↑
13 Jan 2019, 18:14
I looked around a bit and couldn't find a quick answer, maybe you know of one?
I started writing code the other day and realized that I was writing it inside more lines than necessary (due to my newness about coding and how AHK interpreter works in general)
for example, I had this code:
I read somewhere that combining multiple expressions into one line speeds up script performance in terms of speed, did what I do above by "minifying" my AHK code also increase my scripts speed performance? I tried to use a script that checks this but I'm too incompetent at this point to implement it correctly
I'm wondering if anyone knows of a guide I could reference that can tell me what can go all into one line and what can't?
I'm using AHK v1.1.30.01. I haven't been able to dabble with v2 yet, but will the way code is written in v2 also help with more improved performance "one-liners" or condensed code?
Thanks a bunch for your response in advance!
The only purpose minification has in autohotkey is to make it harder for others to read. That's it.
Useless whitespaces and comments are omitted by the interpreter before execution, so there's no impact in that phase. There's only impact in the first run by design of any interpreted language, while the script is being parsed. Although whatever anyone comes back with regarding slowing or hogging down autohotkey during the parsing phase will be so absurd they will be only be able to convince themselves that it actually does *something* measurable by human standards, in their snippet sized scripts. Actual code lines carry far more weight than white space or commented lines.
Informal test after coming out of LoadFromFile() including overhead of executing the exe and anything else the debugging in visual studio may add, since i really won't waste my time in-depth testing this:
1 million inline comment lines and last line is a simple assignment ~500-600 ms
1 million blank lines and last line is simple assignment ~300ms.
100K lines of simple assignments ~600-700 ms.
1 million lines of simple assignments ~6000 ms, and ~3700 ms stopping after LoadIncludedFile(), skipping preparsing expressions and other stuff.
and I bet you a hershey's chocolate the majority of the 300ms of the blank lines test is because of external overhead unrelated to the routine that rolls through the lines.
I would say this would only matter if you are launching an external script repeatedly, like using Run("script.ahk") inside a crazy loop, but even then, for 99.9999999999999% of the scripts the operating system and the underlying ops of the run command will overshadow the skipping of whitespaces or comments. Disk will also affect read speeds.
Creating subexpressions only has an above marginal effect in v1, specially since people will rarely hit the number of expressions to actually make it worth it, as they will eventually stumble upon a statement that can't be placed inside an expression. In v2 subexpressions carry less impact than in v1, even less because of non-expression statements. Although if you keep it to yourself it's a non-issue, emphasis on bolded part here
and waste people's time.
Scr1pter wrote: ↑
13 Jan 2019, 19:21
Well, the most important thing is that it is readable for you.
If it's the case, then it's fine, but once you get problems and post the codes here, it might be more difficult to read, trace and understand.
You can also (v2 only) place subexpressions in a more readable format using parenthesis, if you insist on this. You don't have to use a comma before each subexpression anymore, or bank roll them into a paragraph.
Code: Select all
; do stuff
check ? itdo : itdont,
You also have to consider the weakest link (or slowest in that case) in what you are interacting with. If you are going to be loop hitting or spamming any of file system, complex regex, COM, run commands and some types of dllcalls, it doesn't matter how many whitespaces or comments you remove, or how many subexpressions you cram in, because these operations can be orders of magnitude slower than typical script logic. Just like you can't make your car go faster by shaking out the floor mats outside to remove the weight of the dust.
You can still do this as a post processing stage, once you are done editing, defeating the convenience of the language itself.
There are however good practices in creating performant code in its own execution context, while still being readable and sometimes improving readability, that apply to pretty much any language, interpreted or compiled.