Re: WTF is up with memory usage nowadays?

[Eric Wong <e@80x24.org>]

Sam Saffron <sam.saffron@gmail.com> wrote:
> As to who is at fault here, it is a little bit of "everyone" in a big bucket.

I agree.  At least everyone who was blindly upgrading hardware :)

But yeah, memory usage really is a whack-a-mole affair and
programmers need to constantly watch out for this.

> - The new GC is far more memory hungry than 1.9 line, even with
> `RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5` it is still a lot more space
> than it used to
> 
> - Ruby have been very slow at dealing with the "elephant in the room"
> which is larger processes, stuff like
> https://bugs.ruby-lang.org/issues/12967 goes ignored and is sadly
> unlikely to happen for upcoming release

I suggest re-ping ruby-core every week or two about these things.
Goes for anyone for just about any maintained project :)
Sometimes stuff is honestly forgotten, not conciously ignored.

> - The current focus for "Ruby" is 3x3 (ruby 3 being 3 times faster)
> ... there is no focus on reducing memory usage

Yeah, I was disappointed about that, too.  And I think it was
too lofty of a goal and marketing hype.

> - Most people use default c memory allocator, despite tcmalloc
> offering quite a decent win
> https://github.com/SamSaffron/allocator_bench

I haven't checked in a while, but doesn't tcmalloc hold
once-allocated memory forever?  But yeah, I remember tcmalloc
having good fragmentation avoidance, at least.

Unfortunately, tcmalloc being C++ means it's less-debuggable to
ordinary C programmers; so it wasn't something I wanted to deal
with myself.

And I thought jemalloc was the accepted standard, nowadays;
though I don't notice a difference from glibc
(I cap both at one arena for MRI).

> - mime types gem is a pariah... apparently EVERY install of rails
> needs to hold 46 megabytes of mime types in memory cause ... I don't
> know why ... (even with 'mime/types/columnar')

Eeep!  I guess I'm lucky to not have that...

> - Booting a rails app eats up half a million slots in your ruby heaps,
> clearly the vast majority of this is unneeded waste. Stuff like
> keeping the string "MIT" in memory 125 times forever cause "rubygems",
> jumps out.  There is zero focus anywhere to fix this issue.

...Or that problem.  Though I do sometimes wish pure Ruby could
have a reasonable way to use the rb_fstring C API
(for dedupe+freeze).

But yeah; aside from obscure projects, I've mostly left Ruby due
to the expectation to use JS, accept ToS and have accounts on
non-Free services; in addition to...

> - Ruby heaps grow too fast, even if you put on the breaks, it is hard
> to diagnose how you reached 7000 heaps at runtime when 6000 of them
> are empty.

...the unpredictability of GC.

> Overall there is tons that can be done, but unfortunately there is no
> focus anywhere to fix stuff.

Maybe it starts with things like not top posting :)
Unfortunately, most mail processing software, even Email::MIME
in Perl (which I use for hosting the archives), still requires
loading an entire message into memory :<  Gross, but at least
I only have one full message in memory at once; even for
rendering threads with 368 messages