“Up to 23% less node memory” in XRPL 3.3.0 does not mean a network-wide average. RippleX engineers compared two mainnet nodes: after upgrading from 3.2.0 without trimming to 3.3.0 with trimming, their RSS changed from 20.1 to 17.4 GiB (−13%) and from 19.4 to 15.0 GiB (−23%), respectively. The figures are averages from the stable period starting on day 5 after launch.
On Linux/glibc, after cache sweeps, malloc_trim(0) returns unused heap pages; on other platforms, it’s a no-op. This is an RSS optimization, not a consensus speedup. The sample is limited to two nodes with different configurations, so the results can’t be generalized. Node operators should focus on before-and-after curves for the same machine and age. Would you look at absolute GiB or the change after upgrading?
Sources: Release notes https://xrpl.org/blog/2026/xrpld-3.3.0 |RippleX measurements https://dev.to/ripplexdev/memory-in-an-xrpl-node-explicit-heap-trimming-after-cache-sweeps-4bi9 |XRPLF announcement https://x.com/XRPLF/status/2118433306962505833
Disclosure: Participating in the Binance Square Write to Earn content campaign; eligibility and rewards are subject to the platform’s terms and are not guaranteed. Not investment advice.
$XRP #XRPL