Wireshark-bugs: [Wireshark-bugs] [Bug 5802] Rewrite&cleanup wiretap/file_wrappers

Date: Wed, 6 Apr 2011 12:51:44 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5802

--- Comment #18 from Guy Harris <guy@xxxxxxxxxxxx> 2011-04-06 12:51:43 PDT ---
> Actually when GZBUFSIZE is 4K, uncompressed data is read in 8K chunk ;/ but it's easy to fix.

Assuming that there's not a reason why it's reading two buffers in.

> Anyway what you think about adding fstat() to get filesystem blocksize?

At least some versions of the standard I/O library do that, so it might be a
good idea; we might want to have autoconf and CMake checks to make sure the
stat structure has st_blocksize - looking at documentation for _fstat() on MSDN
indicates that there's no st_blocksize on Windows, so we'll need a #define to
control whether to check it anyway.  Falling back on 4K as the block size if we
can't get it from _fstat() is probably reasonable.

> Maybe standard i/o is aligning seeks to block size?

It might be, depending on the version of stdio.  I remember older versions not
doing so, but when I say "older versions" I mean "AT&T's System V code from
about 1987 or so", so....

> Or some compiler optimizations? (I have wireshark compiled with -O0 :>)

I *suspect* that's not it - my guess is that the bulk of the overhead is
probably either I/O overhead or copying overhead, and the latter is either
kernel code or libc code or both.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.