[Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>]

On Wed, Jul 13, 2016 at 10:53 AM, Paul Offord <Paul.Offord@xxxxxxxxxxxx> wrote:

Hi,

 

I recently measured some load and filter times with and without a LUA postdissector plugin called TRANSUM.  I tried three different scenarios:

 

·        No LUA - without any plugins other than those shipped as standard

·        Bypassed LUA – with TRANSUM but a preference set so that on entry to the postdissector immediately returns to Wireshark

·        LUA Enabled – with TRANSUM enabled

 

The test file was a 47MB pcapng file with mostly web traffic.  Almost all of the data packets would have been scrutinised by TRANSUM in some detail.

 

I timed loading the file and then filtering with the expresssion tcp.len>0.  The timings were:

 

	No LUA	Bypassed LUA	LUA Enabled
Load of file	1.0s	2.5s	5.4s
Filter with tcp.len>0	1.7s	2.9s	5.2s

 

The thing that surprised me was the impact of just having the LUA loaded, even if it immediately returned to Wireshak (the Bypassed LUA scenario).

This somewhat matches my experience with embedding Lua into another (highly optimized) product.  There was a fairly significant performance impact associated with just starting up the Lua environment (even if that environment only called a single script whose contents was "return").

Then again that "significant" performance impact was (IIRC) an increase in CPU usage of about 15% (so 40% CPU usage increased to 46% usage) not the 100+% run time change you're seeing between "No Lua" and "Bypassed Lua."

It certainly gives a reason to (continue) not accepting Lua-based dissectors into Wireshark.

But it does beg the question if there's some optimization to be done.