> Reducing CPU load can be useful even in tasks containing IO. Oh absolutely, this is a huge part of my day to day work. But even for this I tend to prefer looking at a WALL report as it include both information. I see no need to ign...byroot (Jean Boussier)
> it is not about adding a sampling profiler, it is about adding a CPU time profiler that does not sample. Well, the issue description talk of CPU-time, but it also talk about sampling (`timer_create(3)` etc). So yes, it's a CPU-time ...byroot (Jean Boussier)
Unless of course fork isn't available. Alternate: #7930, #7933 Fix: #7930, #7933 When bundler inline has to install gems, it loads more dependencies than when it goes through the fast path of all gems being installed. One of them is `...byroot (Jean Boussier)
Ref: https://github.com/ruby/json/commit/fff25c9f4b9c `StringValuePtr` use `volatile` so the compiler is less likely to re-use the register. But regardless, we should GC_GUARD `str` as we no longer reference it after `GETMEM`. https:/...byroot (Jean Boussier)
> I understand the idea that batching helps in this case where you want to explicitly flush, but that's a pretty specific example, e.g. it's uncommon to even call IO#flush at all in Ruby. Not specific to Ractor, but I relatively often...byroot (Jean Boussier)
[Bug #21860] If a thread was holding this lock before fork, it will not exist in the child process. We should re-initialize these locks as we do with the VM locks when forking. Co-Authored-By: John Hawthorn <john@hawthorn.email> Co-aut...byroot (Jean Boussier)
byroot (Jean Boussier)12:18 PM Ruby Feature #21950: Add a built-in CPU-time profiler