We have all used Box<T> before in our Rust code. It’s a glorious type, with great ergonomics
and flexibility. We can use it to put our values on the heap, but it can do even more
than that!
struct Fields {
@@ -118,7 +118,7 @@ don’t think this can reasonable be changed.noali
that can bring clear performance wins (for noalias on &mut T, those were measureable). So the only question remains:
How much performance does noalias on Box<T> give us now, and how many potential performance improvements could we get in the
future? For the latter, there is no simple answer. For the former, there is. rustc has no performance improvements
-from being compiled with noalias on Box<T>.
I have also benchmarked a few crates from the ecosystem with and without noalias on box, and the results
+from being compiled with noalias on Box<T>, but this isn’t really representative since rustc mostly uses arenas instead of box internally.
I have also benchmarked a few crates from the ecosystem with and without noalias on box, and the results
were inconclusive. (At the time of writing, only regex-syntax, tokio, and syn have been benchmarked.) regex-syntax showed no changes. Tokio showed a few improvements without noalias
which is very weird, so maybe the benchmarks aren’t really good or something else was going on. And syn tended towards minor regressions without noalias, but the benchmarks had high
jitter so no real conclusion can be reached from this either, at least in my eyes, but I don’t have a lot of experience with benchmarks. Therefore, I would love for more people
diff --git a/posts/index.xml b/posts/index.xml
index 0a42dc4..c186ec9 100644
--- a/posts/index.xml
+++ b/posts/index.xml
@@ -153,7 +153,7 @@ don’t think this can reasonable be changed.</p>
that can bring clear performance wins (for <code>noalias</code> on <code>&mut T</code>, those were measureable). So the only question remains:
<strong>How much performance does <code>noalias</code> on <code>Box<T></code> give us now, and how many potential performance improvements could we get in the
future?</strong> For the latter, there is no simple answer. For the former, there is. <code>rustc</code> has <a href="https://github.com/rust-lang/rust/pull/99527"><em>no</em> performance improvements</a>
-from being compiled with <code>noalias</code> on <code>Box<T></code>.</p>
+from being compiled with <code>noalias</code> on <code>Box<T></code>, but this isn’t really representative since rustc mostly uses arenas instead of box internally.</p>
<p>I have also benchmarked a few crates from the ecosystem with and without noalias on box, and the <a href="https://gist.github.com/Nilstrieb/9a0751fb9fd1044a30ab55cef9a7d335">results</a>
were inconclusive. (At the time of writing, only regex-syntax, tokio, and syn have been benchmarked.) regex-syntax showed no changes. Tokio showed a few improvements without noalias
which is very weird, so maybe the benchmarks aren’t really good or something else was going on. And syn tended towards minor regressions without noalias, but the benchmarks had high
diff --git a/tags/rust/index.xml b/tags/rust/index.xml
index b3b2813..1fe4f31 100644
--- a/tags/rust/index.xml
+++ b/tags/rust/index.xml
@@ -153,7 +153,7 @@ don’t think this can reasonable be changed.</p>
that can bring clear performance wins (for <code>noalias</code> on <code>&mut T</code>, those were measureable). So the only question remains:
<strong>How much performance does <code>noalias</code> on <code>Box<T></code> give us now, and how many potential performance improvements could we get in the
future?</strong> For the latter, there is no simple answer. For the former, there is. <code>rustc</code> has <a href="https://github.com/rust-lang/rust/pull/99527"><em>no</em> performance improvements</a>
-from being compiled with <code>noalias</code> on <code>Box<T></code>.</p>
+from being compiled with <code>noalias</code> on <code>Box<T></code>, but this isn’t really representative since rustc mostly uses arenas instead of box internally.</p>
<p>I have also benchmarked a few crates from the ecosystem with and without noalias on box, and the <a href="https://gist.github.com/Nilstrieb/9a0751fb9fd1044a30ab55cef9a7d335">results</a>
were inconclusive. (At the time of writing, only regex-syntax, tokio, and syn have been benchmarked.) regex-syntax showed no changes. Tokio showed a few improvements without noalias
which is very weird, so maybe the benchmarks aren’t really good or something else was going on. And syn tended towards minor regressions without noalias, but the benchmarks had high
diff --git a/tags/unsafe-code/index.xml b/tags/unsafe-code/index.xml
index 3a3a13b..1a72d7f 100644
--- a/tags/unsafe-code/index.xml
+++ b/tags/unsafe-code/index.xml
@@ -153,7 +153,7 @@ don’t think this can reasonable be changed.</p>
that can bring clear performance wins (for <code>noalias</code> on <code>&mut T</code>, those were measureable). So the only question remains:
<strong>How much performance does <code>noalias</code> on <code>Box<T></code> give us now, and how many potential performance improvements could we get in the
future?</strong> For the latter, there is no simple answer. For the former, there is. <code>rustc</code> has <a href="https://github.com/rust-lang/rust/pull/99527"><em>no</em> performance improvements</a>
-from being compiled with <code>noalias</code> on <code>Box<T></code>.</p>
+from being compiled with <code>noalias</code> on <code>Box<T></code>, but this isn’t really representative since rustc mostly uses arenas instead of box internally.</p>
<p>I have also benchmarked a few crates from the ecosystem with and without noalias on box, and the <a href="https://gist.github.com/Nilstrieb/9a0751fb9fd1044a30ab55cef9a7d335">results</a>
were inconclusive. (At the time of writing, only regex-syntax, tokio, and syn have been benchmarked.) regex-syntax showed no changes. Tokio showed a few improvements without noalias
which is very weird, so maybe the benchmarks aren’t really good or something else was going on. And syn tended towards minor regressions without noalias, but the benchmarks had high