Wireshark-dev: Re: [Wireshark-dev] r48218: Remove the emem slab feature

From: Jakub Zawadzki <darkjames-ws@xxxxxxxxxxxx>
Date: Sun, 10 Mar 2013 13:46:20 +0100
On Sat, Mar 09, 2013 at 08:03:41PM -0500, Evan Huus wrote:
> On Sat, Mar 9, 2013 at 3:48 PM, Jakub Zawadzki
> <darkjames-ws@xxxxxxxxxxxx> wrote:
> > Right now no, but there was implementation of sl_free_all().
> 
> Granted, but I don't (off the top of my head) have a potential use case for it.

What about O(1) free time for proto nodes? (common case).

> Regardless, without proof the other way (that emem slabs were an improvement),
> the less code we own the better.

Ok, I performed some stress test for ws_slab vs g_slices for quite big capture file.

Test performed with one liner:
  for ((i=0; i< 10; i++)); do echo $i; time ./tshark -n -r /tmp/big.pcap -V > /dev/null; sleep 600; done
one tshark run at the time (most computation was done nightly).

/tmp is mounted ramfs, tshark compiled with CFLAGS="-O2 -pipe -w"

I cheated a little and both tshark are based on r47905, but with patches:
  ws_slab-tshark was build with patch: http://pastebin.com/raw.php?i=rMexZBsh
  g_slices-tshark was build with patch: http://pastebin.com/raw.php?i=YdA50LKL

but I'd rather wait for some other results/conclusions before I repeat test with r48218 and r48217

big.pcap is:
  Number of packets:   7284 k
  File encapsulation:  IEEE 802.11 plus radiotap radio header
  File size:           944 MB

                  ws_slab        g_slices
user            17m20.988s      19m30.194s
user            16m59.147s      19m17.288s
user            16m40.835s      19m42.880s
user            16m43.241s      19m24.307s
user            16m47.508s      19m25.764s
user            16m53.047s      19m44.216s
user            16m38.085s      19m9.822s
user            16m57.067s      19m28.897s
user            17m5.540s       19m29.994s
user            17m8.343s       19m40.903s

avg:            16m55.380s      19m29.426s
                 +/- 25s         +/- 20s

                       1m17.023s
                     (~8% +/- 4%)

To be honest, I thought the result would be on statistic error boundary,
and still we're NOT using sl_free_all().


Generally I'm fine with this patch even if we loss about ~1% (in normal use),
but ws_slab is faster than g_slices :P

Regards,
 Jakub.