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

[greg Landrum]

Hi,

[Sorry for the long delay, a variety of obstacles arose which prevented me 
from looking into this any further until today.]

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

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

****   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
         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.  :-)

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.

-greg