mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-20 18:22:09 +01:00
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
This commit is contained in:
parent
a5b18f8a65
commit
82e2d6001a
@ -35,6 +35,8 @@ const char aes_c_id[] = "$Id$";
|
|||||||
* significantly faster than using OpenSSL's EVP code (by about 27%)
|
* significantly faster than using OpenSSL's EVP code (by about 27%)
|
||||||
* and faster than using OpenSSL's AES functions (by about 19%).
|
* and faster than using OpenSSL's AES functions (by about 19%).
|
||||||
* The counter-mode optimization saves around 5%.
|
* 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_AES
|
||||||
#undef USE_OPENSSL_EVP
|
#undef USE_OPENSSL_EVP
|
||||||
@ -183,6 +185,10 @@ void
|
|||||||
aes_crypt(aes_cnt_cipher_t *cipher, const char *input, size_t len,
|
aes_crypt(aes_cnt_cipher_t *cipher, const char *input, size_t len,
|
||||||
char *output)
|
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;
|
int c = cipher->pos;
|
||||||
if (!len) return;
|
if (!len) return;
|
||||||
|
|
||||||
|
@ -752,6 +752,9 @@ strmap_set(strmap_t *map, const char *key, void *val)
|
|||||||
void *
|
void *
|
||||||
digestmap_set(digestmap_t *map, const char *key, void *val)
|
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 *resolve;
|
||||||
digestmap_entry_t search;
|
digestmap_entry_t search;
|
||||||
void *oldval;
|
void *oldval;
|
||||||
|
@ -2148,6 +2148,14 @@ routerlist_remove_old_routers(void)
|
|||||||
/* Build a list of all the descriptors that _anybody_ recommends. */
|
/* Build a list of all the descriptors that _anybody_ recommends. */
|
||||||
SMARTLIST_FOREACH(networkstatus_list, networkstatus_t *, ns,
|
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,
|
SMARTLIST_FOREACH(ns->entries, routerstatus_t *, rs,
|
||||||
if (rs->published_on >= cutoff)
|
if (rs->published_on >= cutoff)
|
||||||
digestmap_set(retain, rs->descriptor_digest, (void*)1));
|
digestmap_set(retain, rs->descriptor_digest, (void*)1));
|
||||||
|
Loading…
Reference in New Issue
Block a user