[C++-sig] Re: conversion of python dictionary to shared_ptrs

Raoul Gough RaoulGough at yahoo.co.uk
Mon Apr 5 00:36:28 CEST 2004


David Abrahams <dave at boost-consulting.com> writes:

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
[snip]
>> Option 2. means the C++ code knows the static types of the elements,
>> which gives you the fastest possible code for what you do in C++. It
>> introduces overheads on the Python side, since every operation on the
>> container requires a call through the Boost.Python code. 
>
> I'm not convinced these overheads you're referring to are real.
> Accessing a native Python dict or list from Python requires a call
> through Python's 'C' code that's much like Boost.Python's C++ code.
> There's probably one extra level of function indirection, but I doubt
> that counts for much in most cases.

Hmmm... I'd always assumed there was more to it than just an extra
indirection, doesn't it have to search for a matching overload and do
type compatibility checking as well? In particular, the purely Python
solution doesn't care what kind of object you insert in a container,
so it doesn't have to check types or look up a from-Python converter.

I must admit I never really looked into in much detail, but I did see
a substantial performance difference between filling a Python list
from Python and filling a std::vector<int> from Python (about a factor
of five). Is this more than you would expect?

On the other hand, C++ code searching the vector or sorting it is
about fifteen times faster than Python code doing the same on a Python
list, so it really does depend on the mix of operations you're doing.

>
>> For example, this wouldn't make much sense if you spend all the time
>> filling the container from Python and then do one simple operation
>> on it in C++.
>
> Probably the reason, though, is the amount of effort you expend
> writing wrapping code in that case.
>
>> Option 3. means converting the whole container for each call (either
>> from a C++ container to Python or vice versa). I guess it also
>> introduces a problem if you want code on the non-native side to modify
>> the container, since you'd then have to convert the container back and
>> replace the original.
>
> Right.
>
>> As for which is the easiest to use, I would say probably option 2
>> would be, except that I haven't yet documented the new indexing suite
>> properly, and I don't think the original suite has much std::map
>> support.
>
> Mmm, I'm eagerly awaiting those docs.

I've recently managed to get some paid employment, so I've had to put
this work on the back burner for a while. I'm still hoping to get the
docco ready by the end of next week (April 16) in time for the Python
conference in Oxford.

-- 
Raoul Gough.
export LESS='-X'





More information about the Cplusplus-sig mailing list