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] RFC: sorted value_string + bsearch

From: Anders Broman <anders.broman@xxxxxxxxxxxx>
Date: Fri, 23 Apr 2010 10:04:31 +0200
Hi,
Looking at the code again I think it looks promising a further enhancement could
Be to add a flags field indicating the search method if the value_string is "full"
E.g. all values 0-x used the value could be directly used as an index to the sought string.

I just need to find the time to do some profiling/tests...

Regards
Anders 

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Jakub Zawadzki
Sent: den 22 april 2010 23:40
To: Ed Beroset; Developer support list for Wireshark
Subject: Re: [Wireshark-dev] RFC: sorted value_string + bsearch

On Thu, Apr 22, 2010 at 10:47:14AM -0400, Ed Beroset wrote:
> I may have missed it, but have we measured to see if this is worth optimizing in the first place? 

I have some old callgrind log, where match_strval (for 58736 frames) is called a lot:

 from dissect_ieee80211 58,7k
 from ieee_80211_add_tagged_parameters 228k

It's problem with ieee80211 dissector, but when you grep dissector sources:

#v+
$ grep -Ir 'val_to_str' ./ | wc -l
3621

$ grep -Ir 'match_strval' ./ | wc -l
305
#v-

It's a common thing to use these functions.

> If not, I think I'd favor choosing code

Come on, this code require only adding:
   static const VALUE_STRING_FAST(some_value_string_array);

I don't see much difference between using:
   value_to_str_fast(..., &foo_fast) and value_to_str(..., foo)

If you don't like automatic variable naming I can replace VALUE_STRING_FAST with:

  #define VALUE_STRING_FAST_INIT(x) = { array_length(x)-1, x }
  static const value_string_fast foo = VALUE_STRING_FAST_INIT(bar);

Dissector maintainer is free to use old/new (or write his own) function he want, but putting 57 new lines to core won't hurt.

> clarity over an inconsequential speedup.

ATM I don't have working profiler to benchmark wireshark, but I made some _raw_ benchmark [1], for 5k entries and searching 0 to 6k three times

Average time for 16 tests: 
 val_to_str_fast: 0.02s
      val_to_str: 1.56s

Sorry for not providing real-life benchmark.

Cheers.

[1] http://szara.chmurka.net/value_string-bench.c

___________________________________________________________________________
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