From: Eric Wong Date: 2018-04-30T04:38:46+00:00 Subject: [ruby-core:86770] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC sam.saffron@gmail.com wrote: > I really really like this, its a free performance boost with > almost no downsides. Almost... I need to revisit [PATCH 4/2] (native_sleep) due to th->status changes and finalizers running causing compatibility problems. > I guess the simplest way of measuring it would be to run > something like Discourse bench with and without the patch. In > theory we should get better timings after the patch cause it > decreases odds that the various GC processes will run when the > interpreter wants to run Ruby. Depends on benchmark, if a benchmark is pinning things to 100% CPU usage then I expect no improvements. But I don't think real-world network servers are often at 100% CPU use. > Implementation wise it seems like you only have it on > rb_wait_for_single_fd PATCH 3/2 added select() support, too > , is there any way you can make this work > with the pg gem? It just builds on libpq per: > https://www.postgresql.org/docs/8.3/static/libpq-async.html so > maybe you would need to expose an end point for libpq to > "trigger" partial gc processes just when you send a query? I'd need to look more deeply, but I recall 'pg' being one of the few gems which worked well with 1.8 threads because FDs were exposed for Ruby to select() on. So I'm not sure what they're doing these days where they give the Ruby VM no way to distinguish between waiting on external resource (FD) or doing something CPU-intensive locally. I guess you can cheat for now and do: Thread.new do r, w = IO.pipe loop { r.wait_readable(0.01) } end Which will constantly do incremental mark + lazy sweep. But cross-thread free() is probably still bad on most malloc implementations... If 4/2 worked reliably (tests pass, though...)): Thread.new { loop { sleep(0.01) } } (gotta run, back later-ish) Unsubscribe: