>The value_string gsm_dtap_elem_string is >not realy used as a
value_string but >rather as
>an array where the string is fetched by >a pointer.
Then it should not be a value_string but just be an array of pointers to char.
As far as value_string's are concerned, some of them are quite large
and thus val_to_str() becoming quite expensive since we have to do a
linear search of this array.
Most such large value_string's are such that only very few of the
entries are "common" and occur frequently in a trace while most of the
entries occur very infrequently.
I think it is not realistic to optimize the value_string's by hand to
sort them in the order of frequency.
What someone should implement (ill do it next week or so unless
someone else wants to give it a try) to optimize access speed and the
cost of val_to_str() is to change
val_to_str() to
1, When we find an entry in a value_string keep track of the index
into the array in a variable cnt.
2, Swap the entry at cnt (the one we found) with the entry cnt>>1
(IFF cnt!=cnt>>1).
This should be a very very cheap operation, we just swap two 32 bit
integers and two pointers.
This would also mean that the "frequent" entries in the value_string
would bubble upwards towards the top of the value_string and thus
become "faster" to find next time we search for it.
This change would not require any changes to the value_string
definition, it would be a very cheap way to dynamically sort the
entries according to frequency at run time and would probably
make access to, in particular, the huge nt_status for smb and the
dcerpc_status for dcerpc protocols faster.
Any takers for implementing and testing this?
On 8/29/05, Anders Broman (AL/EAB) <anders.broman@xxxxxxxxxxxx> wrote:
> Hi,
> The value_string gsm_dtap_elem_string is not realy used as a value_string
> but rather as
> an array where the string is fetched by a pointer.
> item =
> proto_tree_add_text(tree,
> tvb, curr_offset, 5,
> gsm_dtap_elem_strings[DE_LAI].strptr);
>
> GSM_A will is not described by asn1, so the dissector will not be
> asn2eth:ified.
>
> Brg
> Anders
>
> -----Original Message-----
> From: ethereal-dev-bounces@xxxxxxxxxxxx
> [mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of ronnie sahlberg
> Sent: den 28 augusti 2005 10:23
> To: ethereal-dev@xxxxxxxxxxxx
> Subject: [Ethereal-dev] value_string
>
>
> I just finished going through and checking all value_strings in
> dissectors and did find more than a handful ones that were not
> properly terminated with a {0,NULL} entry.
>
> These should all be fixed now.
>
>
> In GMS-A there was a very peculiar value_string : gsm_dtap_elem_string
> that just looks very wrong.
>
> Could one of the telco people have a look at that one or should we
> just wait until it is ASN2ETHified?
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>