[ruby-core:86827] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC

[e-mail] wrote:
> require 'benchmark/ips'

> So this moves us from 200-210 ops/s to 240 ops/s. This is a
> major perf boost, still to see if it holds on the full
> Discourse bench, but I expect major improvements cause waiting
> for SQL is very very very common in web apps. 

Thanks! I wasn't even aiming for a speed improvement.
Any memory measurements?
I guess benchmark/ips won't show that.

> I do not expect too much benefit in concurrent puma workloads,
> but for us in unicorn we should have a pretty nice boost.

It really depends on CPU usage, I don't think it's common for
any server to be using all available CPU at all times; so
Ruby should be able to get background work done during
wait states.


One difference in MT is cross-thread malloc/free (malloc returns
a pointer to be freed in another thread) isn't too great in most
malloc implementations I've studied.

Though Ruby sometimes hits cross-thread malloc with or without
sleepy GC, it may be more common with sleepy GC.  Before sleepy
GC, free() happens most in threads which malloc() most,
so it gets returned to the correct arena/cache most often.

Haven't checked jemalloc in a while, but I remember cross-thread
was weak there in the 4.x days; maybe it's improved.  glibc
wasn't terrible there and (I think it was) DJ Delorie was taking
it into account in his updates; but I haven't kept up with that
work.  Forcing fewer arenas via MALLOC_ARENA_MAX also mitigates
this problem.

I seem to recall Lockless Inc. malloc being REALLY good at
cross-thread malloc/free, but used too much memory overall in my
experience.  cross-thread malloc/free can be a common pattern
for message-passing systems

Anyways, maybe this will encourage me to try getting wfcqueue
into glibc malloc as I threatened to do in [ruby-core:86731]
(/me shrivels in fear of GNU indentation style)

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>