ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] ew function(s) proto_tree_new_item_get_val_..()

From: Anders Broman <a.broman@xxxxxxxxx>
Date: Wed, 12 Jan 2011 23:37:46 +0100
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.
? 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.

I stand by keeping your API orthogonal and clean.
What's orthogonal?
Regards
Anders

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

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe