On Wed, Jul 13, 2016 at 10:53 AM, Paul Offord <[email protected]> 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.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
