I don't find the $ctimems bug you report.
In your ctimems alias, you make use of the value stored in %ctimems.ctime but its only updated when the variable is first created: $left($calc(
%ctimems.ctime + (($ticks - %ctimems.ticks) / 1000) + .0001),-1)
No - because $ticks-%ctimems.ticks makes up the difference.
How much benefit is there from !command and $~identifier
For a single call its VERY MINOR; as in pico-seconds faster. Across multiple calls it can trim off milliseconds or even, depending on the script, seconds to minutes in the case of long-running loops.
I would hope that mIRC keep a record of what aliases are defined and where so it doesn't have to scan every script every time it needs to scan for a script alias. But if it does, that could be a significant amount of time, especially with large and complex scripts..
and use of a hash table rather than variable lookup
This is dependent on the mIRC environment. The more variables in use the slower referencing variables becomes. By creating a hashtable with only related variables, non-related data doesn't have to be skipped over before getting to the desired value. This is a small time save(if any at all if there's no variables) but can be impactful on heavy-processing scripts if there's a lot of variables in play.
Worth doing then.
using several inline calculations rather than one $calc?
Given the context, $calc is
very slow. It has to parse brackets, process the identifiers & variables fed into it, etc etc. That parsing takes a fair bit of time. Inline arithmetic is much faster but very limited: can only be done in variable-setting statements, only one math operation can be done, neither side of the operator can contain spaces.
So for a very big $calc, it would be quite unreadable if split into multiple inline %x %y + %z lines. But for simple calc's (esp. those embedded in a string, it could be quite beneficial without losing readability.
Is this something I should be doing throughout my script?
The short answer is no. The methodologies used above are to push processing time as low as possible; many of which come from scripting speed-challenges from back in the day. Instead I recommend coding the way that makes sense to you with the following guidelines:
- Always use ()'s around conditions and {}'s around code-blocks for if-then-else statements, while statements, events, and alias declarations. There's some wonkiness with condition resolution that the brackets fix. Also makes your code far more readable
- Spaces after commas. If you are passing parameters into an identifier, use a space after the comma to separate the parameters. It doesn't affect the code in any way but does make the code alot clearer.
- Don't use pipes(|) to separate commands unless forced; instead use a new line. Again, makes your code quite a bit easier to read
I already follow most of these because I value readability. I did find a gotcha with missing brackets, so my code now has brackets everywhere. I don't currently use spaces after commas, but I will start doing this.
P.S. $ticks appear to increment in 15-16ms steps. So the first tick after ctime clicks over will be on average 8ms pas the second. Adjusting the $tick by 8 will stop you getting ms = 000 with ctime not clicked over.I will post revised code here a bit later for people to look at.
