BIND 10 #1959: Implement perfdhcp control logic

BIND 10 Development do-not-reply at isc.org
Mon Sep 10 16:25:11 UTC 2012


#1959: Implement perfdhcp control logic
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  marcin
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:  Sprint-
  enhancement                        |  DHCP-20120917
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  DHCP
  perfdhcp                           |  Estimated Difficulty:  0
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by marcin):

 Replying to [comment:16 tomek]:
 > Replying to [comment:10 marcin]:
 > > > CommandOptions::printCommandLine() should also print specified
 command-line parameters as they are. That may seem redundant, but there is
 very good reason to print them out. It is easy to reproduce the case,
 based only on log file. It is very useful to keep a format that can be
 copy-pasted easily into the next execution.
 > >
 > > Good suggestion. Tool now always prints the command line as it was
 typed in.
 > No, it doesn't. I've tried to run:
 > {{{
 > ./perfdhcp -4 -r 1000 all
 > }}}
 > and it didn't print out command-line.

 Try ./perfdhcp2 -4 -r 1000 all. That one will work :-)

 >
 > > > '''perf_pkt4.cc''' and '''perf_pkt6.cc'''
 > > > Methods writeAt() and writeValueAt are not tested.
 > >
 > > I added tests for these methods and .... I found bug in writeValueAt.
 Thanks for this! :-)
 > :-)
 >
 > > > '''pkt_transform.h'''
 > > > writeValueAt() is intended to be used for integer types only, right?
 Aren't there a simpler way to do it?
 > >
 > > They are integers only. What is the simpler way?
 > I was thinking about something without the loop.
 > {{{
 > switch (sizeof(T))
 > {
 >     case 1:
 >     // code for storing a single byte
 >     case 2:
 >     // code for storing a word
 >     case 4:
 >     // code for storing a double word
 >     ...
 > };
 > }}}
 >
 > It would be faster than a loop. Keep in mind that those methods are used
 many, many times per second. If you are tired of this ticket, turning this
 into a @todo is ok for now.

 I am still not confident about the benefit from changing the current code
 to switch statement but I added a @todo for this.

 >
 > > > PktList type - I bow to your superior template handling techniques,
 sir. How many nested templates are there? 6? :) Seriously speaking, I do
 not understand that PktList definition.
 > >
 > > I don't like having so many nested templates but in fact boost is
 about templates and some of them may become quite complex in use. The
 multi_index_container is documented here:
 > >
 [http://www.boost.org/doc/libs/1_51_0/libs/multi_index/doc/tutorial/index.html]
 > Explaining a magic trick takes away the feel of mystery. ;-)
 >
 > > I also added some more comments in the typedef.
 > Thanks.
 >
 > > > printIntermediateStats(): ostringstream objects don't have to be
 explicitly initialized to empty strings. The default constructor does that
 as well, but is faster. ++it in "for" loop doesn't have to be written in a
 separate line.
 > >
 > > Corrected. Why are the default constructors faster here?
 > Because with ostringstream(""), you create a string object that is
 passed to ostringstream constructor. When using default constructor, no
 such object is created. The difference is speed is marginal, though.
 >

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


More information about the bind10-tickets mailing list