<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Tobias,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">On Tue, Jan 17, 2017 at 7:27 PM, Tobias Oberstein <span dir="ltr"><<a href="mailto:tobias.oberstein@gmail.com" target="_blank">tobias.oberstein@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Antonio,<span class=""><br><br></span>
Fantastic!!<br>
<br>
Actually, if this is true (performance), this would be wonderful - I can spare my nerves (hello C++, you are a moooonster!), and eat my cake ..<br>
<br>
The benchmarks<br>
<br>
<a href="http://capnpy.readthedocs.io/en/latest/benchmarks.html" rel="noreferrer" target="_blank">http://capnpy.readthedocs.io/e<wbr>n/latest/benchmarks.html</a><br>
<br>
for scalar attribute access look awesome (close to mere instance access).<br>
<br>
Structured value access (lists/dict): bigger difference. I am also concerned about GC pressure - is it still "zero copy"?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">yes: under the hood, capnpy objects are represented as immutable strings; then the generated classes contain accessors which look like this (overly simplified):</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">class Point(_Struct):</div><div class="gmail_default" style="font-size:small"> @property</div><div class="gmail_default" style="font-size:small"> def x(self):</div><div class="gmail_default" style="font-size:small"> offset = statically_known_x_offset + self._offset</div><div class="gmail_default" style="font-size:small"> return struct.unpack_from('q', self._buf.s, offset)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">where self._buf.s is a string.</div><div class="gmail_default" style="font-size:small">The nice thing is that the pypy JIT does a very good job at optimizing struct.unpack_from: if you look at the generated code, you see that it loads the 8 bytes directly from the in-memory buffer. So, it's very close to optimal performance.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For lists is the same: when you look up a list field, you get a wrapper around the very same buffer, then the custom __getitem__ does the actual lookup in memory. Note that currently lists on pypy are slowish, but I should be able to solve the problem in the near future.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small">(note: there is no automatic conversion to unicode, although I might add an option for that in the future).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I don't understand what you mean by dicts are there are no dictionaries in capnproto.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Note also that capnpy is serialization only: there is no support for RPC stuff.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note: I am purely interested in performance on PyPy ..<br>
<br>
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?<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">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 :).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">ciao,</div><div class="gmail_default" style="font-size:small">Anto</div></div></div></div>