Nmap Development: Re: Performance thoughts

["majek04" <nmap () forest one pl>]

Hi,
> >      Hmm. UltraScanInfo::numIncompleteHosts is taking the most of
> >      resources.
> >      What's this function doing you ask?
> >      unsigned int numIncompleteHosts()
> >                      { return incompleteHosts.size();}
> Good find.  Sheesh, that size() performance is pathetic.  Especially
> since the STL guarantees that size() on a list is a constant-time
> operation.  So implementations are required to store the size as a
> variable rather than iterate through the list each time you ask for
> the size.  Does anyone know what is going on here?  If you compile
> with -O2, and don't include -g, do you still see this huge performance
> difference?
Hmm, I didn't knew this about ".size()".

Of course you're right, here are some tests:(Debian sid on x86)
Compilation: "./configure --without-openssl"
Test: "callgrind ./nmap -sS -n -T5 127.0.0.1/22 -p22"

Default nmap compilation:
C(XX)FLAGS=""           32.51s user 0.39s system 99% cpu 33.115 total
The same with debugging information:
C(XX)FLAGS="-g"         30.85s user 0.37s system 99% cpu 31.317 total

And with forced optimizations:
C(XX)FLAGS="-O0"        30.44s user 0.37s system 99% cpu 31.019 total
C(XX)FLAGS="-O1"        8.10s user 0.28s system 99% cpu 8.432 total
C(XX)FLAGS="-O2"        7.07s user 0.29s system 99% cpu 7.403 total
C(XX)FLAGS="-O3"        6.76s user 0.29s system 99% cpu 7.096 total

We see that removing "-g" changes nothing.
It seems that default nmap compilation is done without any "-O".


> I like these graphs.  What are you using to create them?
Like Richard Moore suggested, callgrind and kcachegrind.

Cheers
Marek Majkowski




_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev