pflua-match: Work on arrays of packets, not pointers

This change makes the filter function much tidier, but massively increases performance variance on small data sets (it evens out on larger ones). It retains the property of having no CNEWI calls, as does the sink_cnewi branch, but not master.


On 10/24/2014 06:42 PM, Diego Pino wrote:
>> local seen, matched = 0, 0 -   while ptr < ptr_end do -
>> local record = ffi.cast("struct pcap_record *", ptr) -      local
>> packet = ffi.cast("unsigned char *", record + 1) -      local
>> ptr_next = packet + record.incl_len -      if pred(packet,
>> record.incl_len) then -         matched = matched + 1 -      end 
>> +   for _,packet in ipairs(packets) do
> 
> I googled it up as it also interested me. First I found this page
> http://springrts.com/wiki/Lua_Performance#TEST_9:_for-loops. It
> seems that pairs and ipairs can be 200% slower than indexing. The
> bottom line is do not use pairs and ipairs for critical code.
> 
> I wondered if this applied too for Luajit so I coded a similar test
> at https://gist.github.com/dpino/647b9d2e12aa8ff859b4 and it turns
> out that in Luajit ipairs is "only" 80% slower than indexing, but
> pairs is much more slower than ipairs and indexing. Pairs is 5
> times slower than ipairs and 9 times slower than indexing.
> 
> --- Reply to this email directly or view it on GitHub: 
> https://github.com/Igalia/pflua/pull/65/files#r19349576


Interesting datapoint! That would explain quite a bit of the
performance hit this version had. I'll try to avoid (i)pairs when
feasible. It looks like table.insert is worth avoiding too!

[An argument against the array approach is that it doesn't generalize
all that well to pflua-filter; it makes the code there messier - then
again, we could just leave pflua-filter alone].

Would you like me to benchmark pflua-match without pairs against the
version you merged the other day?

Kat