Re: "String builder"-style optimization

[Sean Conner <sean@...>]

It was thus said that the Great J Doe once stated:
> 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 ?

  I wrote some code that records which line Lua runs (in Lua---the
debug.sethook() function is great for this).  I just simply extracted the
line from the code and saved it to a file [1]).  I found it a unique way to
view the code from an execution point of view [2].

  You don't have to record the actual lines---you could just record which
lines were hit how many times.  This will show you the most often executed
code but not the longest running code [3].  Using both methods should tell
you what's running and for how long.

  -spc (Mostly, I don't bother [4] as Lua has been fast enough for me)

[1]	Here's a run of LuaRocks that I recorded as a test:
	http://boston.conman.org/2015/02/12/luarocks-run.txt

[2]	http://boston.conman.org/2015/02/13.1

[3]	There's a difference.  For example:

		local x = 1
		
		for i = 1 , 1000000 do
			x = x + 1 -- [1]
		end

		sleep(5) -- [2]

	Here, the line marked 1 will run most often, but the line marked 2
	will take the longest to run.

[4]	At work, I'm processing gobs of SIP messages per day using Lua/LPeg.
	This is code that is running on the global phone network and has not
	been optimized.  There have yet to be any complaints on performance.