On 01/13/2011 02:55 PM, Anders Broman wrote:
Jeff Morriss skrev 2011-01-13 18:27:
Anders Broman wrote:
Jaap Keuter skrev 2011-01-12 22:42:
Hi,
Oke, so now the reason is CPU cycles. Show the profiling; is it
*really* worth it? There was a recent thread around tvb_get_ptr() as
being far more efficient. Profiling disproved that.
Actually I did eventually find Martin's code to be faster than mine,
it just took a better method (tshark instead of GUI) and a much bigger
capture file (or testing on a CPU where memcpy()s are expensive).
? speed was the whole point. Unfortunately I'm not sure how to
profile it. But if no one thinks it's
a good idea I'll drop it.
Well, I can also see a point because it reduces the lines of code a
dissector writer needs in these cases. (I too have found it mildly
annoying when I need to add_item() then tvb_get...() the same thing
because I need to test its value.)
In Lua such a function would be great because one function could
return any type of FT_XXX, but... I'm not sure it would be worth
another 15-20(? maybe I'm exaggerating?) proto_tree_add_*() functions:
there's already too many...
Perhaps proto_tree_add_item_get_gint_val32()
returning values for FT_UINT8, 24 and 32
and an int version would cover most use cases?
I was thinking of using g_value but I think that probably wouldn't be
faster. One would really have to
make a prototype to see if it's worth it I suppose.
Wouldn't that make it feasible to make a complex design compact :-))
I thought of this again recently and looked at implementing it.
It turns out it's not so easy: the integer values are retrieved in a
call from proto_tree_new_item() and (of course) it would make the most
sense to return the value which is already being retrieved.
But to do that, you need the proto_item. To have a proto_item you need
a tree, which obviously we don't always have.
Yes, we could fake it out with temporary proto_items, but at that point
you end up only saving dissector code (not cycles). Doesn't quite seem
worth it...
