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

2 files changed, 9 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;