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

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

From: "Lars Ruoff" <lars.ruoff@xxxxxxxxxxxxxxxxx>
Date: Wed, 21 Nov 2007 10:32:59 +0100
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.