[C++-sig] Profiling object instantiation... a preliminary report

[David Abrahams]

----- Original Message -----
From: "greg Landrum" <greglandrum at mindspring.com>


> Here's a bit of context from before:
> I'm concerned about the amount of time required to create objects in
Boost
> (it takes 2-3 times as long to create a Boost object as to create a
> more-or-less equivalent CXX object).
>
> David has suggested that this is probably due to the attribute
> dictionary.


I suggested that it might be due to a difference in the raw number of
dynamic allocations being performed; the attribute dictionary would
account for 1/3 of those.

.(Which immediately raises the question: if I were willing to
> live with objects with read-only attributes could I avoid this speed
hit?).

Not in Boost.Python v1. V2 will provide this capability, eventually.

> Playing around a bit more with Vtune (Intel's performance analyzer),
I've
> tracked down where time is being spent in my code.
>
> Both these profiles are for creation of 100,000 objects.  Because the
big
> differences appear to be in the amount of time spent in Python code,
I've
> included a bit of detail about time spent in Python21.dll

Err, you didn't provide much detail at all, though...

> ****   CXX Wrapper:  (runtime under profiler 3.2 sec)
> OEChem.pyd    1.48 sec   (this is my extension module)
> Python21.dll  0.93 sec
>          eval_code2              0.21 sec
> ntdll.dll     0.32 sec
>
> ****  Boost.Python Wrapper:  (runtime under profiler 5.2 seconds)
> Python21.dll  2.48 sec
>          call_object             0.38 sec
>          PyObject_GetAttrString  0.34 sec

This part could be due to attribute lookups.

>          eval_code2              0.22 sec
> rdchem.pyd    1.61 sec  (this is my extension module)
> ntdll.dll     0.59 sec
>
> The similarities in the amount of time spent in the extension code
itself
> reassures me that nothing scary is going on behind the scenes;  the
> slowdown is happening in the wrapper layer.
>
> Hopefully I've provided enough information here to let others
understand
> the problem and its cause.  I guess the next step would be to inspire
> someone to take this issue seriously enough to help solve it.  :-)

I'm not planning on making any major changes to Boost.Python v1. If
someone wants to look at this, of course, I wouldn't stop them, but
since I'm planning to retire that codebase and stop maintaining it I
really don't want to make that kind of an investment.

> At 06:41 AM 3/7/2002, David Abrahams wrote:
>
> >Interesting. I'd be very interested to hear how Boost.Python v2
performs
> >on your code, with or without overloads.
>
> Unfortunately, at the moment I don't have the time required to do this
just
> for timing information.  The wrapper itself is in "production" use, so
I
> don't feel comfortable completely switching to the new version until
it's
> reasonably stable.  I can't afford to be constantly updating my
wrapper layer.

Understood. FWIW, I don't expect the interface to change much during the
course of development; most of the important changes involve adding new
features.

-Ddave