cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
<arigo>
trying to use kcachegrind to figure out why f.read() on a large binary file is much slower in pypy3 than in pypy
<arigo>
the difference might come down to pypy2 accumulating pieces in a list of strings and calling join() at the end
<arigo>
whereas pypy3 uses a stringbuffer
<arigo>
well I'm not too sure but there seem to be *less* memcpy-ed bytes in pypy3, but it takes a lot *more* time, because it's a lot less cache-friendly
<arigo>
...ok now kcachegrind itself crashes, stuck into some infinite loop
<arigo>
found a likely culprit: when calling f.read(), we get a byte string with all the data, and then there are two levels that do "builder=StringBuilder();builder.append(s);s=builder.build()"
<arigo>
if the file is bigger than all memory caches, it makes 2x2 more copies of all the bytes
<arigo>
mattip: the point of counting like I suggested is that it doesn't depend on random commits, but only counts the commits exactly in the history of the one we're testing
<mattip>
topic branches off that branch don't count?
<arigo>
branches are ignored, it counts the commits that are parents of the given one
<arigo>
for example, on py3.6 the number is much larger than on default, because all of default's commits up to the most recent merge are also parents of the py3.6 head
<arigo>
also, topic commits that are not merged are never parents of the branch head