Hi Evan, > - We weren't doing anything with the emem slab that couldn't be done with > glib slices.
Right now no, but there was implementation of sl_free_all(). > - Glib slices are much cache-friendlier Do you have any benchmarks/ cachegrind output to proof it? It's quite normal use to iterate over nodes, in old code we tried to allocate all proto_tree nodes in one page. I doubt if glib slice allocator can do better. If you're talking about something else please specify. > - multi-threading friendly True, but I have patch to fix it (when needed). Generally we don't need it to be truly MT-friendly, just make single slab for single edt. > Allows glib to actually return slices to the OS on occasion. The emem > slab would hold onto its memory forever which resulted in a great deal of > wasted memory after closing a large file. False, it was currently used for fvalue_t, item_label_t, proto_node, which generally are allocated for one or two frames (generally number of currently running epan_disset with tree). Generally I'm fine with removing this code, but I dislike when someone criticize my code without proofs :P (It was me, who changed some SLAB_* use to sl_ in r37030) Speaking of which there's still SLAB_ code in packet-tcp.c. ___________________________________________________________________________ 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
