Hi,
There are two roadblocks in this reasoning, which come to light on the
Win32 platform specifically:
1. Not all used functions are exported, so the dynamic linking won't
work with the current code.
2. Exporting data items from one DLL and using them in another won't
work. This will require duplications.
and then there's the push to get plugins into mainstream. I would be odd
to now drive into the other direction... ;)
Thanx,
Jaap
Lars Ruoff wrote:
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.
