04:50 <mattip> hexology: it is difficult to build pyarrow, but it should build successfully

04:50 <mattip> it does not pass tests, it seems they do too much in __del__ for PyPy

04:50 <mattip> https://github.com/conda-forge/arrow-cpp-feedstock/pull/717

08:41 <komasa> Is there some API to get the values reported by `gc.get_stats()` ?

09:39 <cfbolz> komasa: `gc._get_stats()` maybe?

09:47 <komasa> cfbolz: ha, yeah, that seems like exactly what I'd need

14:21 <hexology> thanks mattip. im glad its not just me

14:21 <hexology> i can try to rebuild and post the actual error if that's helpful

14:21 <hexology> i

14:21 <hexology> i'm not sure it's the same as in the conda-forge issue

15:01 <cahoots_> when i do [f(x) for x in array], where f(x) returns x['some_key'], it takes 15x the time of doing [x['some_key'] for x in array] (0.3s vs. 5s, measured repeatedly). is this expected?

15:02 <cahoots_> seems like the jit lacks a sort of inlining of f(x)

15:06 <nimaje> is that code run often? the jit first counts how often code paths get hit, to not spend time on optimizing code that never gets called again

15:17 <cahoots_> nimaje, each time i benchmarked, i ran each piece of code once. len(array) is 13 million

15:20 <hexology> cahoots_: i'd be curious of calling f(x) in a for-loop with .append gets optimized or inlined more effectively

15:22 <cfbolz> cahoots_: is there a way we can reproduce this?

15:34 <cahoots_> cfbolz, the json is ~1gb. but if you make a 13-million element array with like 5 keys with numbers/short strings for values (same data type always for each specific key), you can do just about what i did

15:34 <cfbolz> cahoots_: ok, then please paste us the script that is slow in a gist or something

15:37 <cahoots_> cfbolz, https://gist.github.com/michaeleisel/eebf3a5f3017643e0d02c4229d9b0e6b

15:38 <cfbolz> IndentationError

15:39 <arigato> Alex_Gaynor: your move to check cffi's alloca() against the particular vulnerability described. As far as I can tell it's only saying something like "-fstack-protector is supposed to make it more likely that bugs in alloca() would be found, but it doesn't achieve that on aarch64"

15:39 <cfbolz> cahoots_: anyway, yes, I would expect the function to be inlined

15:39 <cfbolz> cahoots_: but I cannot debug the problem without a runnable example that shows what's wrong

15:41 <arigato> Alex_Gaynor: I may be wrong though, but I won't know just by reading the first few lines of general explanation

15:41 <Alex_Gaynor> arigato: Yes, I think that's right. My question was really "does it use alloca", if yes then we'll probably do a release that rebuilds our wheels witht he fixed compiler.

15:41 <arigato> then yes

15:43 <cahoots_> cfbolz, i've updated it, just doesn't have the full array

15:44 <cahoots_> now it runs at least

15:44 <cahoots_> i don't have time to send over the array unfortunately

15:44 <cfbolz> cahoots_: ok. are the ticker entries floats?

15:45 <cahoots_> cfbolz, they are string of 1-5 letters

15:47 <arigato> cfbolz: note that if the dicts come from JSON, they may have a special representation

15:47 <cfbolz> yep

15:48 <cahoots_> yeah they come from json.load

15:48 <arigato> cahoots_: basically I'm saying I doubt the script will give the observed slow-down out of the box; it's likely to be tied to some of the details of the loop as it occurs in your program

15:49 <cfbolz> cahoots_: which pypy version are you running?

15:50 <cfbolz> indeed, for me the last two versions are always the same speed, no matter what I tried

15:50 <cahoots_> Python 3.10.12, PyPy 7.3.12 with GCC Apple LLVM 13.1.6

15:50 <arigato> I could only imagine a very bad case where the function mapo() happens to be marked as "don't inline" by some earlier unrelated code

15:51 <cfbolz> yeah, but it would have to be really weird, basically

15:51 <arigato> yes

15:57 <cfbolz> right, if I force the marking of mapo as non-inlinable I can get pretty weird effects

20:50 <hexology> https://bpa.st/COCQ does anyone know if this pyproj/cython build failure is fixable to run in pypy? this is beyond my knowledge to debug

20:50 <hexology> or maybe it's a cython 3.x 0.x incompatibility unrelated to pypy, i know it has significant breaking changes

20:50 <hexology> aha yep this is just a cython issue / they aren't pinning their pep 517 build deps correctly https://github.com/pyproj4/pyproj/issues/1321