08:50 <antocuni> pff, I tried to apply my gc-custom-trace-memo branch also to default, and also in that case it's consistently ~5% slower than vanilla default :(

08:58 <antocuni> arigato: do you know what are the gc.trace() calls which are likely to have a bigger impact on performance?

09:17 <antocuni> ok, this is weird. I'm testing performance using this very simple benchmark which exercise the GC: https://paste.openstack.org/show/bEWsqbU3CVgJ5vD81l4b/

09:17 <antocuni> with JIT, my branch is ~3-5% slower

09:17 <antocuni> with --jit off, I don't see any difference

09:19 <antocuni> which is weird: if the problem is that gc callbacks are slower due to my branch, I'd expect the slowdown to show up even without JIT

09:19 <antocuni> unless maybe the reason is that with --jit off everything is slower and so the GC-related slowdown is lost in the noise?

09:46 <cfbolz> antocuni: the jit uses a trace function for the jit frames, right?

09:46 <antocuni> ah, yes

14:36 <antocuni> update on my benchmarks: targetgcbench also shows a reproducible ~8% slowdown, without JIT. So it's likely a real slowdown in the GC, and since it's a small target it's probably easier to investigate

15:11 <antocuni> another update, it's officially the GC

15:11 <antocuni> https://paste.openstack.org/show/bQLF14m37GIgnctQKDPH/

15:12 <antocuni> this is the output which I get by analyzing the targetgcbench PYPYLOG (using a modified version of logparser which prints actual milliseconds instead of CPU ticks)

15:12 <antocuni> it is very clear that the difference is in gc-minor, now I "just" need to investigate why

15:14 <antocuni> (also, I didn't expect that we spend so much time on gc-hardware! But looking at the impl is reasonable because we open and parse /proc/meminfo

15:49 <antocuni> I might have found the problem: the branch introduces an indirection to call _trace_drag_out, so that gc.trace calls the callback which calls gc._trace_drag_out

15:50 <antocuni> by marking the generated callback as _always_inline_, the extra call is removed and it seems that the performance is good again

15:50 <antocuni> see https://foss.heptapod.net/pypy/pypy/-/commit/698189c923789afced487f0e053f29d9669d2f93