peterzhu2118 (Peter Zhu) wrote in #note-4: > Thank you for reporting this issue. I am glad to help, even in this small way. > ... That is great news. I look forward to seeing this merged and eventually released, hopefully in a ...bluz71 (Dennis B)
byroot (Jean Boussier) wrote in #note-2: > So I can somewhat repro. On my machine (macOS/M3) about 4.0 is half-way between 3.3 and 3.4. Thank you byroot. I am most pleased that it is reproducible, especially 3.3 vs 3.4. Note, if I...bluz71 (Dennis B)
Hello, I noticed a performance degradation with Ruby 3.4 when seeding my Rails application, which does image derivation via the Shrine Gem and `libvips` image library. I skipped Ruby 3.4 hoping that 4.0 would magically solve my per...bluz71 (Dennis B)
Thanks Sam, a very nice set of results. Notice that 99th percentile Topic list was faster with the patch, whilst slower with Topic view. So I'm not sure we can say that the patch will always be slower on the worst runs. Query, what...bluz71 (Dennis B)
Hongli Lai's [What causes Ruby memory bloat?](https://www.joyfulbikeshedding.com/blog/2019-03-14-what-causes-ruby-memory-bloat.html) post is most-interesting indeed. That article has given rise to a new issue, opened by Sam Saffron, [...bluz71 (Dennis B)
Outstanding research by Hongli Lai, and superbly presented in a post & video that all of us can easily digest. Sam's new [15667](https://bugs.ruby-lang.org/issues/15667) issue will be very interesting. I tend to agree, if all goes wel...bluz71 (Dennis B)
Very interesting news indeed about Rust. Thanks for the update. Ruby 2.6 came and went, allocator remained unchanged though two nice enhancements were incorporated, transient-heap and disabled THP. Sam Saffron tweeted the other day ab...bluz71 (Dennis B)
Ruby use generally falls into one of two categories: short-lived or very long-lived. For short-lived Ruby scripts MALLOC_ARENA_MAX could, and maybe should, be left as is? For long-lived Ruby processes MALLOC_ARENA_MAX absolutely sh...bluz71 (Dennis B)
sam.saffron (Sam Saffron) wrote: > After spending a bit too much time thinking about this, I would like to recommend **against** any jemalloc related changes and instead to double down on Eric's https://bugs.ruby-lang.org/issues/14759 f...bluz71 (Dennis B)
davidtgoldblatt (David Goldblatt) wrote: > I don't think this benchmark is a useful way to compare performance between versions 3 and 5 of jemalloc. In between them was the advent of time-based purging, where the allocator waits for a w...bluz71 (Dennis B)