Comment # 5
on bug 10580
from Matthieu Patou
(In reply to Michael Mann from comment #4)
> Yes the decryption is painfully slow, but I'm not sure we want the tradeoff
> of the memory usage needed to cache the decrypted packets (especially for
> traces that are much larger than 20MB). The decryption algorithm itself
> seems to do a lot of memcpys in various forms, so perhaps the algortihm
> itself could be optimized?
Most probably the logic can be improved but profiling with perf clearly show
the crypto functions has the hot point :
22.67% libwsutil.so.0.0.0 [.] crypt_rc4_init
15.56% libk5crypto.so.3.1 [.] k5_arcfour_docrypt
12.59% libk5crypto.so.3.1 [.] Transform
10.57% libwsutil.so.0.0.0 [.] MD5Transform
6.05% libk5crypto.so.3.1 [.] krb5int_MD5Update
5.67% libk5crypto.so.3.1 [.] k5_arcfour_init
As of memory, it's about to cache raw data so if the file is 20MB we are
speaking of roughly 20MB to cache (let's say 40 MB if we are really
un-efficient at storing it).
My main workstation has 8GB of ram so I think it's a fair trade off to loose a
bit of memory but not 20s everytime I change the display filter.
We could of course make this caching optional and enabled by default for
DCE-RPC
You are receiving this mail because:
- You are watching all bug changes.