Ask Your Question

Revision history [back]

Define bloat, installer, memory or cpu? Looking at the installer for win64 sizes as a proxy for "bloat" I see:

  • 2.0 (2015-11-18) - 39M
  • 2.2 (2016-09-07) - 46M
  • 2.4 (2017-07-19) - 56M
  • 2.6 (2018-04-24) - 57M
  • 3.0 (2019-02-28) - 57M
  • 3.2 (2019-12-18) - 66M
  • 3.4 (2020-10-29) - 59M

3.2 looks to be a bit of an outlier, 3.2.1 was back down to 57M. The increase from 2.0 to 2.6 was the switch from the GTK to Qt UI and the addition of the extcap interface support. 3.4 gains the new Packet diagram features. All versions have added or improved protocol dissection and added functionality.

To see the increase in "bloat" for dissectors you would have to look at the size of libwireshark (formerly libepan) in installed versions, I'll leave that as an exercise for the interested reader.

The purpose of Wireshark is to allow users to see what's on their network, removing protocol dissectors from the software runs counter to that mission.

A dissector that is not "called" due to no traffic of that protocol being present requires a small amount of memory and no cpu after initial loading. Heuristic dissectors, by their very nature, require some cpu time to determine if their protocol is present when called but can usually be disabled on a per-dissector preference. All dissectors can be optionally disabled via the existing "Enabled Protocols" dialog. These preferences can be saved in a Wireshark "profile".

There are development discussions about a UI and an API to disable dissectors at run-time using some form of grouping but I don't know if that goes as far as stopping the dissectors from registering, they will still be present in the binaries.

You can also build your own custom version including just those protocols you want. Please abide by the Wireshark licence when distributing your own build.