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.
