I have found 2 issues related to the buffer for sendmessage replies from mIRC back to a DLL:
1. Even though mIRC is telling the DLL that dBytes is 20480, and I can get a DLL to correctly receive a DATA parameter containing a text string longer than 10300 bytes, the request for a sendmessage reply sends back nothing if the reply string is greater than 8192, and I was expecting the size to match the 100+$maxlenl of the DATA buffer.
2. There is a significant slowdown when the sendmessage reply is divided into fewer large replies than when divided into many small replies.
I thought it might have been related to the fix of the issue reported in
https://forums.mirc.com/ubbthreads.php/topics/265770/large-number-of-sendmessages-unset-binvars...but I'm seeing the same rate of slowdown in v7.56 prior to that fix, though I had to use smaller &binvar to avoid the fixed glitch.
--
After making some modifications to Saturn's
sha2.dll, I benchmarked my speed vs the original, and was surprised to find that mine was nearly twice as slow when handling large &binvar.
After eliminating other possible causes, I finally tracked it down to the size of the sendmessage reply coming from mIRC back to the DLL. I had assumed that handling the data as fewer larger chunks would be faster than the overhead of making a larger quantity of smaller messages, so based on the increased value for $maxlenl I had increased the number of bytes requested that $bvar(&var,offset,chunk-size) send back to the DLL.
This alias shows the effect of the $bvar string length on the speed. Depending on the string used in /breplace this is creating a &binvar containing either 1/2/3 digit numbers, and the text length of the $bvar(&var,offset,bytes) return sendmessage for a string containing D-digits would be 1037*(D+1)-1. Times are all close to 10x faster when changing 10^7 to 10^6
//var %digits 1 | while (%digits isnum 1-3) { bunset &v | bset &v $calc(10^7) 0 | var %byteval $str(1,%digits) | breplace &v 0 %byteval | var %i 1, %t $ticks | var %a $dll(sha2.dll,sha256,1 &v) | echo -a bytes $bvar(&v,0) byte val: $bvar(&v,1) time: $calc($ticks - %t) | inc %digits } | dll -u sha2.dll
result:
bytes 10000000 byte val: 1 time: 18049
bytes 10000000 byte val: 11 time: 27925
bytes 10000000 byte val: 111 time: 34352
The slowdown is directly related to the length of the sendmessages, so it was nearly twice those times when requesting the same total data by requesting twice as many 518 byte chunks, and was nearly double these benchmark times by requesting half as many 2048 byte chunks.
I cannot see that the code itself is handling the received data in a way that would be causing the slowdown. I had made a similar change to how the DLL reads diskfiles, and was able to get a significant percentage speed boost by increasing the disk read buffer from 4kb to 16kb, so I had assumed I could get the same thing when handling &binvar by requesting strings as long as $maxlenl
The slowdown is also not affected by whether or not I unload the DLL prior to each of the 3 calls.
I encountered issue#1 by trying to edit the DLL to benchmark chunks of 1037*2=2074 bytes. I was getting the expected nearly-double time for 2074-byte chunks when the bytes had 1 or 2 digits each, but was getting just 16 ticks for chunks having 2074 3-digit bytes. The largest size of a chunk that wasn't doing this was 2048, so because the $bvar(&var,offset,2048) length for byte values 111's is 4*2048-1, this means I was getting a blank reply when the $bvar reply string was longer than 8192, which fooled the DLL into thinking the &binvar was zero length.
