Wireshark-dev: Re: [Wireshark-dev] Making zlib a required dependency
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sat, 11 Nov 2017 10:35:55 -0800
On Nov 11, 2017, at 8:05 AM, João Valverde <joao.valverde@xxxxxxxxxxxxxxxxxx> wrote:

> On 11-11-2017 15:21, Pascal Quantin wrote:
> 
>> When looking at the -dev mailing list history, some people were (are?) still building Wireshark without zlib (see for example the thread starting here: https://www.wireshark.org/lists/wireshark-dev/201209/msg00187.html or the fact that people once in a while upload patches to fix build without zlib).
> 
> The question would be why. That message mentions Wireshark is much faster when built without zlib,

To be precise, that message, sent in 2012, said "*At one stage*, building without zlib support meant that opening/reading files was much faster than with." - emphasis mine.

Jakub Zawadzki's followup:

	https://www.wireshark.org/lists/wireshark-dev/201209/msg00189.html

says

	Old wiretap when you disable zlib was using fread() to read data.
	Right now we have our own I/O routines [copied from zlib, slighty modified],
	which is used also when you disable zlib.

	There were some discussion about performance hits in bug #5802[1],
	I have done some benchmarks (on Linux), and times were almost the same.

> I was not aware of that and I find it pretty surprising.

My followup:

	https://www.wireshark.org/lists/wireshark-dev/201209/msg00193.html

explains in more detail:

	As Jakub indicated, we used to use zlib's I/O routines to read capture files, meaning that both compressed *and* uncompressed files were read through those routines; if not built with zlib, we just used the C standard I/O routines.

	We haven't done that since, I think, 1.6; Jakub took some sample code that came with zlib, supporting fast random access (rather than "move backward by rewinding and moving forward", which is what zlib's I/O routines did), and made it work in Wiretap.  That code is used, albeit without the compressed-file support, even if built without zlib.

So there should be *no* slowdown reading uncompressed files if zlib is configured in, as the code path is the same in both cases (except perhaps for some tests for "am I reading a compressed file?" that are compiled out if we don't have zlib configured in).