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

[David Abrahams]

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> 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 

Yeah, but if there's only one overload that's free.

> and do type compatibility checking as well? 

Yeah, but Python has to look up a hash function depending on the key
type.

> 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.

from-Python lookups are usually cost-free.

> 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?

OK, I can't argue with experimental data.  You are correct, sir.

> 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.

OK.

>>> 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.

Great!  Sorry I can't be there.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com