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 <ronniesahlb...@gmail.com> 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 <d...@cubic.org> 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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe