Hi Charles and Soni,
Thank you both for your replies - this clarifies when to and when not to do "table string building".
Charles as an aside - I noticed you mentioned profiling the code. I have been doing this for some code against a VM that replicates a web host that I am protecting. I use os.clock() to time the section of code and spit the times out to a file. I then run test cases that trigger the rule a 1000 times, just to be able to account for the variances in the web stack. I then read and average the values.
But I'm wondering - do people perform other methods of benchmarking ? Is there an approach I can take that gives a better representation of code efficiency ?
Thanks,
- J
> On Jul 3, 2017, at 3:21 PM, Soni L. <fakedme@gmail.com> wrote:
>
>
>
>> On 2017-07-03 04:16 PM, J Doe wrote:
>> Hi,
>>
>> In chapter 2 of "Lua Gems", Roberto mentions the fact that building a string in a loop by concatenating more string data to it on each iteration is wasteful as a new string must be allocated, the existing elements copied, the old string GC'ed (at some point) and the addition of the new portion of the string.
>>
>> The recommendation for optimization is to emulate "string builder" functionality by storing each piece as an element in a table and then calling table.concat(t).
>>
>> I am wondering if this is also a good pattern for building a regular string that has multiple concatenations . . . but say on the order of 5 to 10 concatenation operations:
>>
>> t = {"Banned UA:", bad_ua, "reason: ", reason_ua, "stats", clck_elapsed}
>> s = table.concat(t, " ")
>>
>> Is the possible performance benefit negligible for "small" string concatenation operations like this such that it's preferable to use the more common .. syntax for concatenation ? I am looking to squeeze every last bit of speed out of the code as it is running in a Web Application Firewall (ModSecurity 2.9.x).
>>
>> Thanks
>>
>> - J
>>
>
> Lua already combines multiple concatenations into one. It all becomes a single OP_CONCAT.
>
> On the other hand, Lua does not combine multiple array initializations into one.
>
> --
> Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.
>
>
