viewtopic.php?f=96&t=124617&p=556019#p556019
See this above post. Comma will slow down the AHKV2 scirpt instead. So suprisingly, the document says the complete opposite of the fact.
Therefore, the description of comma's performance in V2 Document needs to be rewritten. It might mislead newcomers into using discouraged programming practices.
Document for comma is wrong. Topic is solved
Re: Document for comma is wrong.
Thanks for reporting. I've fixed this.
Re: Document for comma is wrong.
The documentation for comma uses the example x:=1, y+=2, ++index, MyFunc(). A simple benchmark of this example vs. putting the expressions on multiple lines shows that separate lines take 23% longer. So the "fix" is no more correct than the original document.
The linked topic compares a sequence of single assignments to a comma-delimited sequence of assignments, where each assignment takes a single literal number. Direct assignment of a single literal value to a single variable is optimised to avoid the expression evaluation function. The benchmark results are not relevant to any other expression.
Combining expressions with a comma is often faster regardless of how the expression is evaluated, simply because there is a per-line execution overhead. In particular, preemptive message checks occur before each line of code executes. (Lines which are combined using the continuation mechanisms count as one line.)
Both the old and new documentation make a broad generalisation which is bound to be mistaken in some cases. It can be omitted entirely. If micro-optimisation hacks are important to a user, they can figure out for themselves what is best in the context of their script (or they can follow poor advice from the forum without testing it, I suppose).
The linked topic compares a sequence of single assignments to a comma-delimited sequence of assignments, where each assignment takes a single literal number. Direct assignment of a single literal value to a single variable is optimised to avoid the expression evaluation function. The benchmark results are not relevant to any other expression.
Combining expressions with a comma is often faster regardless of how the expression is evaluated, simply because there is a per-line execution overhead. In particular, preemptive message checks occur before each line of code executes. (Lines which are combined using the continuation mechanisms count as one line.)
Both the old and new documentation make a broad generalisation which is bound to be mistaken in some cases. It can be omitted entirely. If micro-optimisation hacks are important to a user, they can figure out for themselves what is best in the context of their script (or they can follow poor advice from the forum without testing it, I suppose).
Re: Document for comma is wrong. Topic is solved
Thanks for the clarification, @lexikos. I've removed it.
Return to “Suggestions on Documentation Improvements”
Who is online
Users browsing this forum: No registered users and 7 guests