The problem really boils down to how objects are destroyed.
In C, you simply call free().
In C++, you have to:
- check if there are any complete class instances contained in your
class, and recursively destroy them
- check the vtable and call the appropriate destructor functions (more
than one when doing inheritance)
- call free()
When you have multiple objects sequentially in memory in C, you can
just free() the whole block and be done with it - this is why emem
(and now wmem) block allocation provides such a performance boost. In
C++ you still have to recursively destroy members and call destructor
functions on each individual object (though you can then theoretically
just free() the whole block at that point).
Quick performance note from my wmem testing: when allocating 1024
blocks of memory, then batch-freeing them all (which should more or
less represent the usage pattern in our dissectors) the wmem block
allocator performs about 10x faster than g_malloc/g_free, which are
themselves slightly faster than raw malloc/free.
You can cheat and ignore the complex requirements for C++ objects only
if they are POD (Plain Old Data) types, but this limits their
usefulness (no virtual functions, no non-POD members, no destructors,
etc). Specifically, none of the STL containers are POD.
On Fri, Jun 21, 2013 at 1:38 PM, ronnie sahlberg
<ronniesahlberg@xxxxxxxxx> wrote:
> Technically you could use smart pointers, or other types too.
>
> But beware the performance impact, and do get numbers before changing.
>
> Ethereal/Wireshark does an enormous amount of small allocations and frees.
>
> One of my primary goals when we added the first emem allocators were
> performance.
> Make it very cheap, near zero cost for both allocations and free,
> especially for a lot of small shortlived allocations.
>
> This is important especially if you have really big captures where
> the original malloc()/free() real allocators became impossibly slow.
>
>
> On Thu, Jun 20, 2013 at 11:08 PM, Dirk Jagdmann <doj@xxxxxxxxx> wrote:
>>> C++. It snuck in with Qt. Should we allow C++ in the rest of the code or
>>> at least use C++ compilation everywhere?
>>
>> A tough call. If we go C++ we should have a plan to use the STL classes with our
>> concept of memory (allocator scope). I've started a short discussion last year,
>> but somebody found out, that using STL objects on the heap with the C++
>> allocators doesn't have the same semantics (and really doesn't work) with our
>> packet or file lifetime scopes.
>>
>> However a second approach with C++ objects managed by smart pointers and those
>> smart pointers being aware of the packet/file/application lifetime might work.
>> We should research this, write guidelines how to use C++ objects in Wireshark
>> and then make a decision if we want to allow C++ features everywhere.
>>
>> Another advantage would be that we can use real C++ exceptions.
Yes please :)
>> --
>> ---> Dirk Jagdmann
>> ----> http://cubic.org/~doj
>> -----> http://llg.cubic.org
