summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2007-02-26 18:01:23 +0000
committerNick Mathewson <nickm@torproject.org>2007-02-26 18:01:23 +0000
commit82e2d6001af8867851f43dbfa0f56997f503aa29 (patch)
tree6032b39a8b5da3b609aeeda2d46b2d0933a164a7
parenta5b18f8a6580fc239b508b98ce498e859dc0c65c (diff)
downloadtor-82e2d6001af8867851f43dbfa0f56997f503aa29.tar.gz
tor-82e2d6001af8867851f43dbfa0f56997f503aa29.zip
r11954@catbus: nickm | 2007-02-26 13:01:19 -0500
Note some optimizations that are probably not worth it for 0.1.2.x based on preliminary profiling. svn:r9659
-rw-r--r--src/common/aes.c6
-rw-r--r--src/common/container.c3
-rw-r--r--src/or/routerlist.c8
3 files changed, 17 insertions, 0 deletions
diff --git a/src/common/aes.c b/src/common/aes.c
index df9c4f4d08..fa6de45252 100644
--- a/src/common/aes.c
+++ b/src/common/aes.c
@@ -35,6 +35,8 @@ const char aes_c_id[] = "$Id$";
* significantly faster than using OpenSSL's EVP code (by about 27%)
* and faster than using OpenSSL's AES functions (by about 19%).
* The counter-mode optimization saves around 5%.
+ *
+ * (XXXX We should actually test this more, and test it regularly.)
*/
#undef USE_OPENSSL_AES
#undef USE_OPENSSL_EVP
@@ -183,6 +185,10 @@ void
aes_crypt(aes_cnt_cipher_t *cipher, const char *input, size_t len,
char *output)
{
+ /* XXXX This function is up to 5% of our runtime in some profiles;
+ * we should look into unrolling some of the loops; taking advantage
+ * of alignmement, using a bigger buffer, and so on. Not till after 0.1.2.x,
+ * though. */
int c = cipher->pos;
if (!len) return;
diff --git a/src/common/container.c b/src/common/container.c
index 5f829c29ec..36234743ac 100644
--- a/src/common/container.c
+++ b/src/common/container.c
@@ -752,6 +752,9 @@ strmap_set(strmap_t *map, const char *key, void *val)
void *
digestmap_set(digestmap_t *map, const char *key, void *val)
{
+ /* XXXX We spend up to 5% of our time in this function. We should tighten
+ * it up... but not on the 0.1.2.x series; the HT code has historically
+ * been finicky and fragile. */
digestmap_entry_t *resolve;
digestmap_entry_t search;
void *oldval;
diff --git a/src/or/routerlist.c b/src/or/routerlist.c
index 67cd60de5d..e45676bf9f 100644
--- a/src/or/routerlist.c
+++ b/src/or/routerlist.c
@@ -2148,6 +2148,14 @@ routerlist_remove_old_routers(void)
/* Build a list of all the descriptors that _anybody_ recommends. */
SMARTLIST_FOREACH(networkstatus_list, networkstatus_t *, ns,
{
+ /* XXXX The inner loop here gets pretty expensive, and actually shows up
+ * on some profiles. It may be the reason digestmap_set shows up in
+ * profiles too. If instead we kept a per-descriptor digest count of
+ * how many networkstatuses recommended each descriptor, and changed
+ * that only when the networkstatuses changed, that would be a speed
+ * improvement, possibly 1-4% if it also removes digestmap_set from the
+ * profile. Not worth it for 0.1.2.x, though. The new directory
+ * system will obsolete this whole thing in 0.2.0.x. */
SMARTLIST_FOREACH(ns->entries, routerstatus_t *, rs,
if (rs->published_on >= cutoff)
digestmap_set(retain, rs->descriptor_digest, (void*)1));