I'm not sure if this is possible, but the interpreter could maybe do this on it's own (like when it's reading the script at runtime), if it realizes the lines below are expressions as well, combining them all into one to improve performance. Because oftentimes (but not always) in libraries on the forum or on GitHub, the comma operator is never used either because the user doesn't know of it's existence/that it improves performance or doesn't like it visually to have commas in an expression in their code. Also same case with normal users not using the operator oftentimes.Performance: The comma operator is usually faster than writing separate expressions, especially when assigning one variable to another (e.g. x:=y, a:=b). Performance continues to improve as more and more expressions are combined into a single expression; for example, it may be 35% faster to combine five or ten simple expressions into a single expression.
Comma operator optimization applied automatically from the interpreter
-
Animan8000
- Posts: 58
- Joined: 11 May 2022, 05:00
- Contact:
Comma operator optimization applied automatically from the interpreter
The docs say this:
Re: Comma operator optimization applied automatically from the interpreter
Those notes were written by Chris Mallett over a decade ago. I don't know how often they have been tested to verify whether there is any actual benefit, let alone something like "35% faster". Personally I think that regardless of the actual performance, these notes do more harm than good, encouraging poor style and unrealistic priorities.
35% was probably seen in synthetic benchmarks designed to measure exactly the overhead that the author was looking for. In a real-world script, you are generally not performing the same simple operation over and over in a tight loop. Actual functionality such as Send, DllCall, and various other functions far eclipse the overhead of performing an assignment on its own line.
We're only focusing on this optimization because someone put it in the documentation long ago, not because of any real-world impact that it has, let alone compared to other ways a script or AutoHotkey itself could be optimized. Judging by comments in the source code, Chris did a lot of micro-optimization that's probably been completely defeated simply by changing compilers several times over the years, or even just making a minor unrelated change to some other part of the program. I have learned to avoid premature micro-optimization because the time spent is not commensurate with the long-time benefits.
One of the reasons that combining lines may improve performance is that the program is designed to perform certain tasks between the lines. At the very least, it checks the current ListLines setting (and probably adds each line to ListLines), and it tracks the message check interval. If the interval has been reached, it checks the message queue and dispatches messages, which takes time and may result in new threads launching. In v1, it also applies the SetBatchLines setting, which has a major impact on "performance" (since it is literally designed to slow the script down). Using SetBatchLines -1 and Critical -1 avoids most of this, for good or ill.
Combining lines automatically would cause unwanted changes in behaviour. For instance, a function or loop consisting only of expressions might give the program less opportunity to check for messages, thereby making it seem less responsive. A loop calling GetKeyState might waste more CPU cycles, because the key state might only change when the program checks its message queue, which may not be happening as before.
I have a list of potential optimizations that could be made if I had both time and interest to implement and test them, and plans for more major (internal) changes that would supersede any micro-optimization built on the current implementation. None of this has as much real-world impact as fixing bugs or implementing new features, and there's usually no one else working on any of this.
35% was probably seen in synthetic benchmarks designed to measure exactly the overhead that the author was looking for. In a real-world script, you are generally not performing the same simple operation over and over in a tight loop. Actual functionality such as Send, DllCall, and various other functions far eclipse the overhead of performing an assignment on its own line.
We're only focusing on this optimization because someone put it in the documentation long ago, not because of any real-world impact that it has, let alone compared to other ways a script or AutoHotkey itself could be optimized. Judging by comments in the source code, Chris did a lot of micro-optimization that's probably been completely defeated simply by changing compilers several times over the years, or even just making a minor unrelated change to some other part of the program. I have learned to avoid premature micro-optimization because the time spent is not commensurate with the long-time benefits.
One of the reasons that combining lines may improve performance is that the program is designed to perform certain tasks between the lines. At the very least, it checks the current ListLines setting (and probably adds each line to ListLines), and it tracks the message check interval. If the interval has been reached, it checks the message queue and dispatches messages, which takes time and may result in new threads launching. In v1, it also applies the SetBatchLines setting, which has a major impact on "performance" (since it is literally designed to slow the script down). Using SetBatchLines -1 and Critical -1 avoids most of this, for good or ill.
Combining lines automatically would cause unwanted changes in behaviour. For instance, a function or loop consisting only of expressions might give the program less opportunity to check for messages, thereby making it seem less responsive. A loop calling GetKeyState might waste more CPU cycles, because the key state might only change when the program checks its message queue, which may not be happening as before.
I have a list of potential optimizations that could be made if I had both time and interest to implement and test them, and plans for more major (internal) changes that would supersede any micro-optimization built on the current implementation. None of this has as much real-world impact as fixing bugs or implementing new features, and there's usually no one else working on any of this.
-
Animan8000
- Posts: 58
- Joined: 11 May 2022, 05:00
- Contact:
Re: Comma operator optimization applied automatically from the interpreter
@lexikos I do agree that features and fixes should be the main focus for the language for sure, but working at some point in improving performance could be also benefitical for the language in a few situations. Even if it are a lot of small improvements over time, it will add up more and more, to achieve greater overall performance.
I'm not sure how to explain it properly, but there's like a small minority of people intentionally not wanting to work with AutoHotkey, and they choose to use instead a language like Python, simply because "AutoHotkey is not fast enough to them". But like I said, that's only a small minority of people that might think that and they choose then to use a different language instead.
I'm not sure how to explain it properly, but there's like a small minority of people intentionally not wanting to work with AutoHotkey, and they choose to use instead a language like Python, simply because "AutoHotkey is not fast enough to them". But like I said, that's only a small minority of people that might think that and they choose then to use a different language instead.