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


_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev

Reply via email to