BIND 10 #192: Data source hotspot cache

[BIND 10 Development]

#192: Data source hotspot cache
-------------------------+--------------------------------------------------
 Reporter:  each         |        Owner:  jinmei                                        
     Type:  enhancement  |       Status:  reviewing                                     
 Priority:  major        |    Milestone:  05. 3rd Incremental Release: Serious Secondary
Component:  b10-auth     |   Resolution:                                                
 Keywords:               |    Sensitive:  0                                             
-------------------------+--------------------------------------------------

Comment(by jinmei):

 On in-house list implementation vs std::list.

 I've written a simple performance benchmarks using my framework in the
 experiments/jinmei-onmemdb branch (r2292).

 It focuses on the performance of moving one entry of the list to the head
 of the list.  The implementations are mostly a verbatim copy from the
 relevant part of cache.cc (and my counter proposal version).

 Interestingly, in-house version is much slower than std::list version.
 Here are the results:

 Move-to-front benchmark using std::list with erace/push
 Performed 200000 iterations in 0.031950s (6259780.91ips)
 Move-to-front benchmark using std::list with splice
 Performed 200000 iterations in 0.004197s (47653085.54ips)
 Move-to-front benchmark using in-house list implementation
 Performed 200000 iterations in 0.058643s (3410466.72ips)

 The "with splice" version introduces an additional optimization so that we
 can avoid overhead of erace/push operation.  but the in-house version is
 even slower than the naive erace/push version.  and it's more than 10
 times slower than the std::list+splice version.

 I've not figured out exactly why it was, but one possible explanation is
 the in-house version requires many operations on shared_ptr's, not bare
 pointers, and seemingly cheap operation such as ptr1 == ptr2 or ptr1 =
 ptr2 can be a bit more expensive than it might look.

 This result seems quite informative.  Most notably, when it comes to
 performance, we should measure it rather than guess.

-- 
Ticket URL: <https://bind10.isc.org/ticket/192#comment:38>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development