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

[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

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