Comment # 10
on bug 9949
from Guy Harris
(In reply to comment #9)
> (It might be interesting to see whether caching the address strings even if
> we're not resolving names speeds things up significantly without chewing up
> an unacceptable amount of memory; I guess a capture with a billion different
> IP addresses might be a worst-case example for this, but typical captures
> probably have a *lot* fewer addresses, and if we ever have a problem with
> that, we could treat it as a full-blown cache by keeping a usage count for
> addresses and limiting the number that we cache by purging ones that have
> only appeared a few times.)
Running TShark, reading a very large capture file and printing columns, under
Instruments on OS X seems to show that ip_to_str_buf(), the routine that
actually converts IP addresses to strings, is in the noise.
So it's probably not worth caching the address strings; that's not why the file
took 38 or so CPU seconds to read.
(It also shows that libgnutls and libgcrypt are responsible for at least 15% of
the CPU time, even though there's no decryption to be done here. This Is Not
Good.)
You are receiving this mail because:
- You are watching all bug changes.