[bind10-dev] some profiling on the new in-memory data source

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

Jinmei mentioned this morning that the new in-memory data source is
indeed much more efficient in terms of memory use, but as currently
enabled in #2219 at the cost of a massive performance drop; from the
few scenarios tested, the worst is a basic query for 'www.example.net'
in the root zone; it's about 25-35% of the previous performance.

So I just did a bit of profiling on this, here are some initial
observations (there are probably much more but I would encourage to
take a look at the profile and see for yourself)

I used the root zone, a simple query input of www.example.net A, and
100000 queries through query_bench. My callgrind outputs can be found
at http://tjeb.nl/opendir/profiling/ and can be interactively
inspected with kcachegrind)

1. Most time is spent in LabelSequence::compare(). This is quite a big
change (it was 1.7% of the calls and it now 15.6%) and could perhaps
partly or completely be expected, but right now it seems it is called
rather excessively often (about 50 times per query).
2. The next method where a lot of time is spent is the LabelSequence
constructor itself (when creating from buffer data), called even more
often (most of which because of calls to DomainTreeNode::getLabels())
3. find() is called 2700000 times; 2600000 times of those are from
getAdditionalAddrs (which itself is called 1300000 times, which makes
sense) (i.e. 13 root addresses, 2 lookups per address). find() itself
then calls the construct/compare (mentioned in 1 and 2) 48500000 times
(about 17 times per call to itself, on average, in domaintree.h line 1527)

I'll leave further interpretation of these numbers as an exercise for
the reader for now ;)

Another thing I noticed where we could improve performace rather
easily (but only by a little) is LabelSequence::getHash(), this is not
new but was already present (in fact in the old code this is where
most time is spent); An easy solution (but at the cost of a size_t
increase of the LabelSequence class) would be to store and reuse the
calculated hash of the labelsequence.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEUEARECAAYFAlBgRfAACgkQ4nZCKsdOncVDIACYkPT9Z8k3ZvFk+Bmt9Gj22Z7y
sACgyFCpKAldiymj8bSvzXSQ/JecPYg=
=h69I
-----END PGP SIGNATURE-----