Comment # 8
on bug 9949
from Guy Harris
(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
and
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
address.
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.