On Thu, May 7, 2009 at 4:15 AM, David Manura <dm.lua@math2.org> wrote:
On Wed, May 6, 2009 at 5:14 PM, Alexander Gladysh wrote:
> Today I'm benchmarking iterating a table with ipairs vs. numeric for:... <...>
> 7 [35] GETGLOBAL 5 -2 ; v
What's v? <...>
Ugh. Sorry, seems like I've had a bad day yesterday. I've fixed the benchmark (see below).
To answer a couple of questions from other replies:
1. Why am I compensating for ipairs() function call? I wanted to measure the relative speed of the loop construct itself (numeric vs. generic vs. while). This is not quite correct though. I've removed the compensating call in the fixed test.
2. Am I comparing two solutions to the same problem? I think so. This benchmark came from practical task -- to serialize numeric part of the table before hash part (in loose sense). For example, for arguable aesthetic purposes, this
{ [1] = 1, [2] = 2, [3] = nil, [4] = 4 }
should be serialized as
{ 1, 2, [4] = 4 }
and not as
{ 1, 2, nil, 4 }
Fixed (hopefully) benchmark is attached. Results:
lua ------------------------------------------------------------------- name | rel | abs s / iter = us (1e-6 s) / iter ------------------------------------------------------------------- loop_while_50 | 1.0000 | 98.10 / 20000000 = 4.905000 us loop_while_25 | 1.0145 | 99.52 / 20000000 = 4.976000 us loop_numfor_50 | 1.0499 | 103.00 / 20000000 = 5.150000 us loop_numfor_25 | 1.1172 | 109.60 / 20000000 = 5.480000 us loop_while_5 | 1.1367 | 111.51 / 20000000 = 5.575500 us loop_numfor_5 | 1.3889 | 136.25 / 20000000 = 6.812500 us loop_ipairs_50 | 2.2424 | 219.98 / 20000000 = 10.999000 us loop_ipairs_25 | 2.4672 | 242.03 / 20000000 = 12.101500 us loop_ipairs_5 | 2.9218 | 286.63 / 20000000 = 14.331500 us
The actual difference in speed is not that huge (x2.25 vs x7.5 on broken benchmark).
Here are the bytecode dumps (the difference is also a bit less here, 7 vs. 10 instructions):