BIND 10 #1747: refactor auth::Query so it's reusable
BIND 10 Development
do-not-reply at isc.org
Wed Mar 14 14:11:42 UTC 2012
#1747: refactor auth::Query so it's reusable
-------------------------------------+-------------------------------------
Reporter: | Owner: jinmei
jinmei | Status: reviewing
Type: task | Milestone:
Priority: high | Sprint-20120320
Component: | Resolution:
b10-auth | Sensitive: 0
Keywords: | Sub-Project: DNS
Defect Severity: N/A | Estimated Difficulty: 4
Feature Depending on Ticket: auth | Total Hours: 2.66
performance |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by jelte):
* owner: jelte => jinmei
Comment:
Replying to [comment:10 jinmei]:
> Replying to [comment:9 jelte]:
>
> The revised version looks basically okay and ready for merge. One
> final suggestion: I'd reset datasrc_client_/qname_/qtype_/response_ to
> NULL in reset().
>
ack, done
> > Replying to [comment:7 jinmei]:
> >
> > The cleaner could also be initialized as the first part of process().
I did think of such an approach, but as the object of this exercise was to
reduce object allocation I was hesitant to do so (though this one would
probably not be much overhead).
>
> The construction overhead of this `QueryCleaner` object should be
> essentially nothing more than this:
> {{{#!c++
> Query& query_ref = query_;
> }}}
>
> Anyway,
> so I'm okay with deferring it. Would you open a ticket for that?
>
crap it, that would almost have been more work than actually doing it :p
Ok, added a private class QueryCleaner; which is initialized first thing
in process(). Removed the other calls to vector::clear() and
query::reset(). The multi-query tests should already show that this
cleaner class is used and works (not sure whether it is worth it adding
other methods to inspect the cleaner object is used).
>
> As long as the reserved space is sufficient, reallocation shouldn't
> happen run-time, so unless we repeatedly build a response containing a
> crazy number of RRsets, reallocation shouldn't happen again so soon.
> But it's probably less likely to happen in the first place anyway (we
> could have a crazy number of *RRs*, but it would be very unlikely to
> include a large number of *RRsets*). So I'm okay with skipping this
> cleanup. At least I'm okay with deferring it.
created ticket #1777
Passing back for a final look at those changes :)
--
Ticket URL: <http://bind10.isc.org/ticket/1747#comment:13>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list