Wireshark-bugs: [Wireshark-bugs] [Bug 9949] Buildbot crash output: fuzz-2014-04-02-29441.pcap
Date: Sat, 19 Apr 2014 10:40:57 +0000

Comment # 8 on bug 9949 from
(In reply to comment #7)
> However, the current widget doesn't require that, at least for GTK+ (if it
> does for Qt, we should fix that), so caching address-to-string mappings
> might no longer speed up the initial processing of a file in Wireshark.  If
> it doesn't, we should probably not bother caching them.

We're already caching the address strings - but those aren't se_ allocated.

However, if we're only allocating the strings, and *not* associating them with
the addresses so that we only need to generate the string for a given address
once, I'm not sure why there's any reason to se_ allocate them.

Not se_ allocating them doesn't seem to make processing packet files in TShark,
or reading them in Wireshark; it doesn't make it noticeably faster, either. 
(Presumably this means that

    1) se_ allocating the buffer is cheap


    2) my machine has enough memory - 16GB - so I don't start paging.

Machines with less memory might actually notice the extra memory, so not se_
allocating the names might make processing the capture files faster.)

It would also be interesting to see whether caching address strings even if
we're *not* resolving addresses to names speeds up processing files if there's
plenty of memory - and whether it significantly increases the amount of memory,
given that there's only going to be one copy of the string for any given

Also, *this* file is a USB capture, and there isn't any USB-address-to-name
mapping (I'm not sure what it would be if it existed) *and* there's no caching,
so not se_ allocating the strings at all would, I think, not slow anything down
and would reduce memory usage even more.

You are receiving this mail because:
  • You are watching all bug changes.