AutoHotkey Community

[Atomhrt]

[corrupt]

A safer way would probably be to use the addresses returned for the Null characters to retrieve the results and do what needs to be done at that time and/or save each result to a separate variable. The function could be modified to create an array (well... a sudo array in AHK) containing the results and output the number of results that were stored. That way you would have each result in a separate variable and know how many results were received. Instead of an array the results could be stored in a listview control or wherever needed. As the position of each Null character is known, the strings can be extracted and stored (maybe using lstrcpyn with DllCall) and/or used as needed.

[Laszlo]

[corrupt]

Maybe I'm misunderstanding (I'll take a closer look at your code)... Is there an advantage to using the CharChange function over the method I used in the generic function I posted (other than changing the default character used) for replacing the null characters? At a glance, the CharChange function seems to loop through the resulting string character by character which doesn't look like it would be as efficient.

[Laszlo]

[PhiLho]

The CharChange loops over the buffer only once, changing chars on the fly.
Your loop seems efficient, but I think that internally (inside AutoHotkey), the StrLen calls C language' strlen, which loops over the string until it finds a zero byte. So you loop over the first part, replace the zero, loop again on first part then second part, replace, loop on the first, second and third part, and so on... Even if C is faster than an AHK loop, it is probably still more costly than Laszlo's code.
Again, I doubt user will see a difference on a modern computer, but if you like micro optimizations...
In C, you could have optimized your code by doing the StrLen starting on the last replacement position, but I am not sure if it is possible in AutoHotkey.
[EDIT] Laszlo typed faster than me.
_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

[corrupt]

I was aware that the method I used scanned multiple times internally but it does test faster with the files I used for testing. However, since I needed to test both methods using large loops to see much of a difference and since actual usage probably wouldn't require multiple loops and will depend on the data that is being read, it's probably more a matter of preference. Thanks for the answers .

[corrupt]

After doing a bit more testing I found a couple ways to speed things up a bit more for fun . Instead of using StrLen to search for the next NULL character from the beginning each time, lstrlen can be used with DllCall to specify a different starting address to search from. Surprisingly though, one of the largest speed increases was noticed by using quotes around variable types in the DllCall lines. For example, using "UInt" seems to be approximately twice as fast as UInt. Here's a generic function for either replacing or removing NULL characters that seems quite fast. It only removes/replaces NULL characters though. My interest in this code is that it will also help to speed up CMDret functions.

[Laszlo]

Nice! (I changed the <UInt>'s to <"UInt">'s in my version of Dippy46's analog clock, which speeds it up noticeably, as you say. Thanks!)

When removing the NUL's you shift the whole tail of the string one position to the left, repeatedly, which makes this version still quadratic in running time. If you moved only the portion to the next NUL, and remember to jump over the garbage left, you could save a lot of memory move operations. I wonder if the added complexity is worth the speedup at long buffers.

[corrupt]

Good point with the memory move operations . I'm a bit surprised that the speed is as good as it is considering...

[Chris]

Thanks for mentioning the performance difference between a quoted "int" and an unquoted one. I'll check if that can be remedied.

[PhiLho]

Aha, I always used the version with double quotes, because it looked nicer in my editor... So it was a good deal too...
_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

[Chris]

I think the reason for the worse performance is that any empty variable is considered a possible environment variable, which causes a call to the OS's GetEnvironmentVariable() [which is slow in performance].

There is a plan to have a directive such as #EnvVar Off to turn off automatic fetching of environment variables, which should solve this (as most of you know, it will also solve other serious problems that have been raised).

[PhiLho]

So these are really variables falling to the now classical pitfall?
I suppose these variables are defined only when calling DllCall, because if I write MsgBox %UInt%/%Str%, I get empty strings...
_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

[Chris]

Edit: In v1.0.43.08+, if you use #NoEnv, the performance issue with DllCall is solved.

Older comments (somewhat obsolete):
When you use an unquoted type like "int" with DllCall, all the early stages of expression evaluation see it as an empty variable. Only when DllCall is actually called does it recognize these special variable names as what they were intended. This does not make variables like "int" into reserved names (keywords): they can still be used as though they're normal variables. In fact, you could assign a single character to each of them to solve the performance reduction mentioned earlier.