[#113435] [Ruby master Feature#19634] Pattern matching dynamic key — "baweaver (Brandon Weaver) via ruby-core" <ruby-core@...>
Issue #19634 has been reported by baweaver (Brandon Weaver).
6 messages
2023/05/09
[#113489] [Ruby master Bug#19642] Remove vectored read/write from `io.c`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>
Issue #19642 has been reported by ioquatix (Samuel Williams).
10 messages
2023/05/15
[ruby-core:113513] [Ruby master Feature#19678] Don't immediately promote children of old objects
From:
"peterzhu2118 (Peter Zhu) via ruby-core" <ruby-core@...>
Date:
2023-05-18 13:20:38 UTC
List:
ruby-core #113513
Issue #19678 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Feature #19678: Don't immediately promote children of old objects https://bugs.ruby-lang.org/issues/19678 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- This is an alternate proposal to #19610 where the feature is not configurable and always enabled. GitHub Pull Request: https://github.com/ruby/ruby/pull/7821 References from an old object to a write barrier protected young object will not immediately promote the young object. Instead, the young object will age just like any other object, meaning that it has to survive three collections before being promoted to the old generation. References from an old object to a write barrier unprotected object will place the parent object in the remember set for marking during minor collections. This allows the child object to be reclaimed in minor collections at the cost of increased time for minor collections. On one of [Shopify's highest traffic Ruby apps, Storefront Renderer](https://shopify.engineering/how-shopify-reduced-storefront-response-times-rewrite), we saw significant improvements after deploying this feature in production. In the graphs below, we compare the GC time and response time of web workers that have `GC.delay_promotion = false` (non-experimental group) and `GC.delay_promotion = true` (experimental group). We see that with this feature we spend significantly less time in the GC, 0.81x on average, 0.88x on p99, and 0.45x on p99.9.  This translates to improvements in average response time (0.96x) and p99 response time (0.92x).  In benchmarks, this feature performs better in some scenarios and worse in others. However, these benchmarks are usually not a good indicator as there are few old objects and major collections are not a significant bottleneck. ``` -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- ------------- bench master (ms) stddev (%) RSS (MiB) branch (ms) stddev (%) RSS (MiB) branch 1st itr master/branch activerecord 70.7 0.2 54.4 70.5 0.3 54.7 1.01 1.00 erubi_rails 20.5 2.0 103.0 20.7 2.2 102.2 0.94 0.99 hexapdf 2470.1 0.3 275.6 2475.4 0.7 215.9 1.03 1.00 liquid-c 65.2 1.4 39.8 65.4 0.3 39.7 1.05 1.00 liquid-compile 59.5 3.4 38.9 57.5 3.0 38.3 0.99 1.04 liquid-render 164.3 1.1 36.1 159.8 0.2 35.5 1.02 1.03 mail 135.7 0.2 50.2 135.3 0.1 50.0 1.00 1.00 psych-load 2053.0 0.0 36.4 2003.3 0.1 35.3 1.03 1.02 railsbench 2001.8 0.7 107.1 1965.1 0.0 107.3 1.00 1.02 ruby-lsp 67.1 8.7 94.6 65.1 0.8 92.8 0.97 1.03 sequel 72.4 0.2 40.4 71.3 0.2 40.4 1.01 1.02 -------------- ----------- ---------- --------- ----------- ---------- --------- -------------- ------------- ``` ---Files-------------------------------- Screenshot 2023-04-20 at 11.50.26 AM.png (527 KB) Screenshot 2023-04-20 at 11.50.38 AM.png (350 KB) -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/