05:30 <whitequark_> krono: (both URLs will work indefinitely, the old one just has a 301 Moved Permanently now)

05:30 <whitequark_> folks, i'm seeing PyPy have really bad (worse than CPython, though not by much) performance on what appears on the surface a very simple transcoding function

05:33 <whitequark_> the code in question: https://github.com/cmcqueen/cobs-python/blob/main/src/cobs/cobs/_cobs_py.py

05:33 <whitequark_> the benchmark code and results: https://github.com/cmcqueen/cobs-python/pull/5#issuecomment-2868401572

05:36 <whitequark_> does anyone have ideas as to why it might be slow? it operates on one memoryview and one bytearray, doesn't (or at least, shouldn't at the face of it) allocate besides expanding that byte array, only touches integers otherwise

05:45 <whitequark_> alternately, any pointers to how to find out what makes it slow would be just as appreciated

05:51 <krono> Good point

06:04 <whitequark_> i guess one benefit is that the new URL is shorter and easier to pronounce :)

06:05 <whitequark_> (i'm migrating away the public benefit infrastructure that i run to not share machines with my private infrastructure, partly because i'm concerned one could be used to attack the other, partly because i would like the public benefit infrastructure i run to have a bus factor of more than 1)

06:06 <whitequark_> oh, pypy's terminal is very pretty during the build

06:41 <krono> it is, isn't it?

06:46 <krono> If you want to go down a rabbit hole, the PYPYLOG-env var gives you _a lot_ of info what is going on.

06:47 <krono> For example, if you want to know what the jit is doing, you can do ` PYPYLOG=jit-log-opt:jit-summary:out.pypylog ITERS=100 PURE_PYTHON=1 pypy3 benchmark.py`

06:47 <krono> and look at out.pypylog (it has a… peculiar format tho)

06:48 <krono> (oh, its `PYPYLOG=jit-log-opt,jit-summary:out.pypylog`, a typo, sorry)

06:50 <krono> Here's an example pypylog for a slightly amended benchmark py: https://bpa.st/ZU2A

06:52 <krono> doesnt look toooo bad from first view tho…

07:02 <whitequark_> why is it allocating two objects on each iteration?

07:15 <whitequark_> apparently, removing `memoryview.cast()` and using just `memoryview()` improves performance by a factor of 10 (!)

07:16 <whitequark_> actually it's more like 20

07:17 <whitequark_> 13 MB/s to 236 MB/s

07:30 <LarstiQ> oh that's a nice one

07:33 <whitequark_> someone should probably fix `.cast()` so that a no-op cast doesn't cause this slowdown at least

07:33 <whitequark_> (even if i call `.cast('B')` on a memoryview with format `'B'` it still does the thing where it allocates twice per iteration)

07:35 <whitequark_> casting a memoryview is so slow that ditching memoryview manipulation altogether and using `bytes` (with copying on every iteration that commits a range) is still faster

07:36 <whitequark_> https://github.com/cmcqueen/cobs-python/pull/6

07:36 <LarstiQ> I vaguely recall some problems with implementability of memoryview but that might be years out of date

16:13 <uau> casting to 'c' does not look like it would actually be a "no-op cast" like whitequark_ claimed?

16:13 <uau> it changes the type from 'B' to 'c'

16:18 <uau> i guess he meant the different case he mentioned after that line

16:50 <uau> anyway using memoryview there generally seems to be a bad idea

16:50 <uau> i tried removing memoryview use and decoding is much faster under cpython

16:51 <uau> avoiding copying is not really beneficial for < 255 byte chunks i guess, the cpython overhead per operation is more than that

16:52 <uau> just removing all that stuff would be better for both cpython and pypy here...