On #7727 (moved) we had some profile results that we used to identify bottleneck functions in Tor to optimize. We should get some fresh profiles on 0.2.5.4-alpha once it's out (assuming we merge #9841 (moved)), and then see which of those bottlenecks need the most attention.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items 0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items 0
Link issues together to show that they're related.
Learn more.
One thought I had about that last profile, though: SHA1 was at the top of the list. OpenSSL's PRNG uses a bunch of SHA1, and is ridiculously slow for a userspace PRNG. If SHA1 turns up at the top of the list again, we should investigate whether it's our protocols' uses of SHA1, TLS's uses of SHA1, or OpenSSL's PRNG's uses of SHA1 that are most to blame.
What I most need is information about 0.2.5.4-alpha or later. 0.2.5.4-alpha has some performance improvements that should (I hope) affect the numbers a lot.
[But information about 0.2.5.2-alpha is still useful, because (a) it will let us know what stuff looked like before 0.2.5.4-alpha, and (b) it will help us figure out what the instructions for running perf should say.]
Was this version of Tor built without debugging symbols or something?
It was built with this settings:
./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --disable-silent-rules --disable-dependency-tracking --disable-buf-freelists --enable-asciidoc --docdir=/usr/share/doc/tor-0.2.5.4_alpha-r1 --enable-instrument-downloads --disable-bufferevents --enable-curve25519 --disable-nat-pmp --enable-gcc-hardening --enable-linker-hardening --disable-transparent --enable-threads --disable-upnp --disable-tor2web-mode --disable-unittests --disable-coverage