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.
I stand by keeping your API orthogonal and clean.
Thanks,
Jaap
On 01/12/2011 10:29 PM, Anders Broman wrote:
Jaap Keuter skrev 2011-01-12 22:04:
Hi,
-1.
It adds bloat to the API, adding noting really.
Well if you have
oct = tvb_get_guint8()
proto_tree_add_item()
if(octet==X)
And replace it with
proto_tree_add_item_get_val_uin32(..,(guint8)oct..)
You'd save a call to
tvb_get_guint8() which calls fast_ensure_contiguous() etc
So there'd be some save of cpu cycles at least...
proto_tree_add_item() fetches the value any way so there would be next
to no extra cost there.
Regards
Anders
Thanks,
Jaap
On 01/12/2011 08:51 PM, Anders Broman wrote:
Hi,
Wouldn't it be handy to have a proto_tree_new_item_get_val_ which would
return the value
thus avoiding to having do tvb_get_.. in conjunction with
proto_tree_new_item() when the value
is needed in a dissector?
Would an function per field type be necessary? like
proto_tree_new_item_get_val_int32, proto_tree_new_item_get_val_uint32
etc or is there a smarter way of doing it?
Any one interested in implementing it?
Regards
Anders
