Yaniv Kaul wrote:
Looking at some dissectors, they are not always written too well,
performance-wise.
- definitions of variables inside loops
I.e., as opposed to defining them at the beginning of a function?
Are there compilers where that's less efficient? I'd expect the
compiler to generate code that allocates a stack frame large enough for
all variables that'd be used by all code paths through the function; are
they not doing that?
- dynamic memory allocation of strings, then strcpy'ing them (instead of
perhaps declaring them in a static const array)
I assume by "strings" you're referring to constant strings here, as per
"static const array". Where are some examples of that?
- proto_tree_add_text(), where it'd make more sense to use
proto_tree_add_item() - which I suspect in many cases would be more
efficient.
I.e., the call to "proto_tree_add_item()" doesn't have to compute and
pass in arguments to a format string, whereas "proto_tree_add_text()" -
and all the "proto_tree_add_XXX_format()" calls - do, even if the format
string and arguments aren't being used (because the representation of
the protocol tree item isn't being generated).
I wonder how much of performance improvement we can gain by re-writing /
optimzing / fixing dissectors.
There's probably optimizations we can do; if we have some captures that
heavily exercise particular dissectors, some profiling might be interesting.
