[or-cvs] r9659: Note some optimizations that are probably not worth it for 0 (in tor/trunk: . src/common src/or)

[nickm at seul.org]

Author: nickm
Date: 2007-02-26 13:01:23 -0500 (Mon, 26 Feb 2007)
New Revision: 9659

Modified:
   tor/trunk/
   tor/trunk/src/common/aes.c
   tor/trunk/src/common/container.c
   tor/trunk/src/or/routerlist.c
Log:
 r11954 at 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.



Property changes on: tor/trunk
___________________________________________________________________
 svk:merge ticket from /tor/trunk [r11954] on 8246c3cf-6607-4228-993b-4d95d33730f1

Modified: tor/trunk/src/common/aes.c
===================================================================
--- tor/trunk/src/common/aes.c	2007-02-26 17:37:09 UTC (rev 9658)
+++ tor/trunk/src/common/aes.c	2007-02-26 18:01:23 UTC (rev 9659)
@@ -35,6 +35,8 @@
  * 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 @@
 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;
 

Modified: tor/trunk/src/common/container.c
===================================================================
--- tor/trunk/src/common/container.c	2007-02-26 17:37:09 UTC (rev 9658)
+++ tor/trunk/src/common/container.c	2007-02-26 18:01:23 UTC (rev 9659)
@@ -752,6 +752,9 @@
 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;

Modified: tor/trunk/src/or/routerlist.c
===================================================================
--- tor/trunk/src/or/routerlist.c	2007-02-26 17:37:09 UTC (rev 9658)
+++ tor/trunk/src/or/routerlist.c	2007-02-26 18:01:23 UTC (rev 9659)
@@ -2148,6 +2148,14 @@
   /* 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));