Wireshark · Wireshark-dev: Re: [Wireshark-dev] Startup speed up - remove dissectors?!

["Kukosa, Tomas" <tomas.kukosa@xxxxxxxxxxx>]

Hi,

it sounds good!
But I can imagine that it will not be easy task.
To define dependency somehow, check them and fulfil them during runtime
could be quite difficult.

Based on my past investigations it seems that it is possible to reduce
time spent in fields registration (proto_register_field_array) from 50%
of startup time to less than 20%. I hope it is not cosmetic effect. :-)
This time reduction would be based on some C code changes and few
assembler lines.

If we agree to do that than we could check after implementation again
where is the bottleneck and if it still make sence to implement
dissector enabling/disabling.

Note this measurement is based on profiling with MSVC6 + WinXP + AMD
Athlon X2.
Different platforms can produce a little bit different results.


Tomas

> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx 
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Lars Ruoff
> Sent: Wednesday, November 21, 2007 10:33 AM
> To: wireshark-dev@xxxxxxxxxxxxx
> Subject: [Wireshark-dev] Startup speed up - remove dissectors?!
> 
> Hi All,
> 
> i start this thread as a parallel discussion to the ongoing 
> startup speed
> assembler usage considerations.
> As goes for me, i'm using Wireshark on a daily basis.
> What i do most often is open a capture file (via clicking on the 
> file), reading rapidly through it, look at some frames, close 
> it again -
> often less than 30 secs for the entire operation.
> In this usage scenario, the slow load time of about 10 secs+ is very
> annoying since it  really breaks the fluidity of operation.
> (I know: having an instance of WS open all time and reusing it with
> different files would probably solve my problem, but it is 
> just not the
> usual document-centric behaviour users are accustomed to)
> I therefore warmly welcome any efforts to reduce startup time.
> 
> However i think doing some low level optimizations will have 
> only cosmetic
> effects.
> The bigger problem is that Wireshark does incorporate more and more
> protocols with every release, and startup time is mostly spent for
> registering all the corresponding dissectors.
> 
> Wouldn't it be more sensible to attack the problem by simply 
> removing some
> of (most of) the dissectors?
> The idea is this:
> Move all seldomly used dissectors to plugins, possibly packaging them
> thematically (e.g. VoIP, Web, Mobile, Network Infrastrucutre, 
> Wireless,
> ...).
> Have all plugins activated by default. => We get the usual 
> "rich" behaviour.
> But now users have the possibility to move the plugins out of 
> the directory
> if they don't ever need the corresponding protocol suites, in 
> order to speed
> up startup time.
> So every user can taylor down WS to have a "light" and quick 
> version for his
> individual needs.
> 
> What do you think?
> 
> The biggest problem in this approach would probably be the many
> cross-references between dissectors that wouldn't be satisfied if some
> protocols are missing.
> 
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>