[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

Maybe it's just me, but this message is sending mixed signals.

Quote:
> While this might give a minor performance boost IFF we by default
> compile the distributable binaries without the debugging support for
then:
> I think, but have not measured, that if we replace the current
> allocator with ep memory that we would have a significant performance
> regression in mainline distribution of binaries unless we start
> compiling our distribution without emem debugging/guardpages etc.
then later:
> since this change, which seems to work for me in my tests would have
> "sideeffects" in that it would not really be possible anymore if we
> want to do debugging/guardpages for the binary w32 distro,   please
> comment.

So what's happening with debugging and guard pages in Win32? Is it just
minor performance degradation, significant preformance regression or
just plain impossible?

> emem debugging/guardpages do not trigger any issues any more so they
> have little value left in binary distribution of wireshark. (we do

Have little value left? what about all those whacko plugins everyone adds
to the program?

Thanx,
Jaap

On Thu, 21 Dec 2006, ronnie sahlberg wrote:

> List,
>
> I have successfully converted 3 of the slab allocated structures into
> ep-allocated() structures and it works for me.
>
> The structures i converted were the temporary slab storage for
> fvalue_t, field_info and item_label_t.
>
> While this might give a minor performance boost IFF we by default
> compile the distributable binaries without the debugging support for
> emem,   this was not the point of the conversion  but rather what
> consequences it would have.
>
> I think, but have not measured, that if we replace the current
> allocator with ep memory that we would have a significant performance
> regression in mainline distribution of binaries unless we start
> compiling our distribution without emem debugging/guardpages etc.
>
>
> Comments please.
> emem debugging/guardpages do not trigger any issues any more so they
> have little value left in binary distribution of wireshark. (we do
> compile win32 binary with both guardpages and debugging?)
>
>
> purpose of this change from slab to ep/emem is not performance. i
> think if will have neglible performance boost when all debugging/guard
> pages are disabled   but rather to remove one small obstacle towards
> making it easier in the future to multithread the dissection of
> wireshark.
> (using ep/emem memory makes it easier in the future if/when we want to
> shoot for multithreaded/multicore dissection.  we would need ep_
> signatures that allocate from a thread-specific heap though but that
> is trivial.)
>
>
>
> since this change, which seems to work for me in my tests would have
> "sideeffects" in that it would not really be possible anymore if we
> want to do debugging/guardpages for the binary w32 distro,   please
> comment.
>
>
> ill check it in tomorrow unless i get "over my dead body" responses.
> (with svn it could always be reversed anyway)
>
>
> ((the changes to the code for the patch is primarily removal of code
> no longer needed when using ep/emem))
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>