Hi Antonio,
The only exception are strings: getting a text attribute means to take a slice of the buffer. However, if the returned value is short-lived, the JIT might be able to optimize the slicing away. (note: there is no automatic conversion to unicode, although I might add an option for that in the future).
Are you aware of https://github.com/alex/zero_buffer ? This emulates Python strings using zero-copy read-only buffer views. I think zero_buffer only supports byte strings not unicode. But for that, maybe it would be cool to have capnpy return zero_buffers upon byte string attribute access, because that should finally provide zero copy .. Caveat: this is a hypothesis I haven't really explored / thought through .. -- Holy grail for me (use case being IPC) would be: Python process 1 mmap's a file shared with Python process 2. Python process 1 puts a string into mmap'ed file, pointer to that is "somehow transferred" to process 2 (eg pushing the index into the mmap'ed file over Unix domain socket .. a single uint64), and Python code in process 2 can do stuff with this string _without_ copying - probably via zero_buffer.
I don't understand what you mean by dicts are there are no dictionaries in capnproto.
Right. Structs.
Note also that capnpy is serialization only: there is no support for RPC stuff.
That's fine .. I don't need RPC (we have WAMP for that in Autobahn/Crossbar.io).
Note: I am purely interested in performance on PyPy ..
In general: I thought it would be a good idea to use capnproto C++ generator, and then cppyy to get the best performance (on pypy). Given there is "antocuni/capnpy", do you think this is a pointless endeavour?
The original goal of capnpy was to be as fast as possible on PyPy. However, if you find that C++ + cppyy is faster, I'd be very interested to know :).
Sure .. right now I cannot progress on cppyy as I can't get the basic example running.. Cheers, /Tobias
ciao, Anto