[C++-sig] Re: conversion of python dictionary to shared_ptrs
dave at boost-consulting.com
Mon Apr 5 03:36:45 CEST 2004
Raoul Gough <RaoulGough at yahoo.co.uk> writes:
> David Abrahams <dave at boost-consulting.com> writes:
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>>> 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
> 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.
>>> 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
>> 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.
More information about the Cplusplus-sig