|
Message-ID: <20150624053906.GQ1173@brightrain.aerifal.cx> Date: Wed, 24 Jun 2015 01:39:06 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH 1/5] dynlink.c: use bloom filter in gnu hash lookup On Wed, Jun 24, 2015 at 02:24:51AM +0300, Alexander Monakov wrote: > Introduce gnu_lookup_filtered and use it to speed up symbol lookups in > find_sym (do_dlsym is left as is, based on an expectation that frequently > dlsym queries will use a dlopen handle rather than RTLD_NEXT or RTLD_DEFAULT, > and will not need to look at more than one DSO). The size of the bloom filter > table minus 1, ghashmask, is stored in the dso struct together with the > hashtable pointer to reduce pointer chasing on the hot path. > --- > src/ldso/dynlink.c | 30 ++++++++++++++++++++++++++---- > 1 file changed, 26 insertions(+), 4 deletions(-) > > diff --git a/src/ldso/dynlink.c b/src/ldso/dynlink.c > index b77c6f6..fa91b39 100644 > --- a/src/ldso/dynlink.c > +++ b/src/ldso/dynlink.c > @@ -54,6 +54,7 @@ struct dso { > Sym *syms; > uint32_t *hashtab; > uint32_t *ghashtab; > + uint32_t ghashmask; > int16_t *versym; > char *strings; > unsigned char *map; > @@ -200,6 +201,19 @@ static Sym *gnu_lookup(const char *s, uint32_t h1, struct dso *dso) > return 0; > } > > +static Sym *gnu_lookup_filtered(const char *s, uint32_t h1, struct dso *dso, uint32_t fofs, size_t fmask) > +{ > + uint32_t *hashtab = dso->ghashtab; > + size_t *bloomwords = hashtab+4; > + size_t f = bloomwords[fofs & dso->ghashmask]; Is this measurably faster than fofs & hashtab[2]-1 ? If suspect not, in which case it seems desirable not to increase the size of struct dso. If it is worthwhile, at least don't sandwich a uint32_t between two pointers where it might incur another 32 bits of padding. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.