Wireshark-bugs: [Wireshark-bugs] [Bug 5109] Moving backwards in compressed captures is extremely
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5109
--- Comment #3 from Guy Harris <guy@xxxxxxxxxxxx> 2010-08-12 16:33:54 PDT ---
With a version of Wireshark that prints out, for seeks in a pcap file, the time
taken to do a seek, along with the current offset and the offset to which it's
seeking, when near the end of the capture file in question, seeking backwards
one packet takes about 1 second.
With the first and last frames marked, going from the first frame to the next
marked frame appears to involve reading every frame in between; forward seeks
are reasonably fast (average of < 1 microsecond), so it doesn't take *too*
long. (The time to do a forward seek in a gzipped file is linear in the
distance between the current offset and the target offset, so seeking forward
one packet at a time is roughly constant, so the time to go forward through the
file is linear in the size of the file.)
Going from the last frame to the previous marked frame *also* appears to
involve reading every frame in between; with backward seeks taking about 1.1
second when at the end of the file, that's not going to be very fast in a file
of 250,000 packets. (The time to do a backward seek in a gzipped file is
currently linear in the target offset, so the time to go from the end of the
file to the beginning is quadratic in the size of the file.)
Currently, "find next marked frame" and "find previous marked frame" are, for
some reason, implemented as "find next frame with a filter of frame.marked ==
TRUE" and "find previous frame with a filter of frame.marked == TRUE", rather
than by just scanning through the list of packets for a displayed frame with
pinfo->fd->flags.marked set. *IF* changing it to do the latter can be done
without breaking anything - I'd have to see why "find {next,previous} marked
frame" are being done that way to see whether there are any subtle reasons why
it couldn't be done that way - *THEN* the case of searching backwards for
*marked* frames in a gzipped capture could be made faster. A similar issue
exits for "find next reference" and "find previous reference". That change
will also make searches for marked or time-reference frames in uncompressed
files, and forward searches for them in compressed files, faster, although the
speedup won't be *as* dramatic.
However, in gzipped files:
1) searching backwards with "find previous frame" is still going to be
slow;
2) the up-arrow in the packet list is still going to be slow;
and if there's some reason why searches for marked frames and time-reference
frames *has* to be done with a filter, then the fix would have to be to make
random access to gzipped files fast.
(And, no, the search isn't hanging forever, in the sense that it's in an
infinite loop and making no progress, so my previous comment plus "the search
is just a special case of find next/find previous" does, in fact, explain
what's happening here; it's just taking long enough that it's unusable in
practice - it'll take over a day to scan all the way back to the beginning of
the file.)
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
