Optimization that in my tests shows 2.7s -> 2.2s #315
Conversation
|
LGTM. Could you update the new block comment to use full sentences and punctuation (full stop at the end of a sentence, blank lines between paragraphs, etc)? |
|
Is it ok now? BTW, I tried moving proc_buf advancement to the end – where your patch located it, and test still ran in 2.2s. I'm sure the tests are correct, wonder how is it possible that your version produces the same output, but in different time. |
Consider indexing long buffers (say 300 chars). E.g. following line:
integer offset=${${buf[start_pos+1,len]}[(i)$needle]}
will gradually go into large indices for first index [a,] and be kept
at large index for second index [,b]. Instead, we can remove already
processed characters from buf:
proc_buf="${proc_buf[offset + $#arg + 1,-1]}"
$offset and $#arg are small, first index will not be large. $proc_buf
will be smaller and smaller and the second index [,-1] will run shorter
and shorter.
|
Merged in 5a98cd3.
Let's have any investigation of this issue happen on a separate ticket; I'd like to close this one. |
New approach to what #312 tried to do. Nicely catches how text pointers (start_pos, end_pos) are advanced and advances proc_buf by the same amount. Runs in 2.2s.