BIND 10 #1753: use object pool for in-memory finder contexts

[BIND 10 Development]

#1753: use object pool for in-memory finder contexts
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  assigned
                       Type:  task   |             Milestone:
                   Priority:  high   |  Sprint-20120320
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:  auth   |           Total Hours:  0
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 trac1753 is *completed*.

 I believe the implementation is mostly straightforward, although it
 has some dirty kludge due to the basic design issue of the entire
 in-memory data source implementation (the "finder" does too many
 things, and the relationship between client/finder/rrset is not well
 clarified).  I'd suggest revisiting these things as part of the
 inevitable cleanup/refactoring.

 But this task has a more fundamental issue: my local benchmark showed
 it didn't improve performance much.  In fact, sometimes it could be
 slower than the code without this change.  Some results:

 I used a simplified (without RRSIGs) root zone snapshot, and performed
 queryperf and querybench using some realistic query samples and a
 single NXDOMAIN-only query (with the latter find() would be called
 twice and other overhead such as name compression should be small, so
 this should be basically advantageous for this optimization).

 I created two brannches for the experiment, trac1753bench0 and
 trac1753bench1.  Both include major optimizations we made so far
 (including the ones not merged to master yet), and bench1 contains the
 changes in trac1753 (bench0 doesn't).

 queryperf result:
 {{{
 w/ 1753
   real query data: Queries per second:   18163.467979 qps
   NXDOMAIN only: Queries per second:     24534.480037 qps
 w/o 1753
   real: Queries per second:              18174.745761 qps
   NXDOMAIN: Queries per second:          23972.857990 qps
 FYI: bind10-devel-20120301
   real: Queries per second:   6458.807839 qps
 }}}

 querybench result
 {{{
 w/ 1753
 real: Processed 965600 queries in 26.074064s (37032.97qps)
 NXDOMAIN: Processed 1000000 queries in 16.556643s (60398.72qps)
 w/o 1753
 real: Processed 965600 queries in 25.970008s (37181.35qps)
 NXDOMAIN: Processed 1000000 queries in 16.015743s (62438.56qps)
 }}}

 Basically, I didn't see any significant difference between the two
 implementations.

 I don't mind dropping the idea at this point.  But I'd at least try
 the comparison again after #1767.  Maybe if we eliminate the
 construction overhead of the base class we see some difference.

 I'll put this to the review queue anyway.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1753#comment:4>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development