Performance discussion

1 files changed, 2 insertions, 1 deletions

diff --git a/docs/community/aoc.html b/docs/community/aoc.html
index 2d960d76..f9ca0b00 100644
--- a/docs/community/aoc.html
+++ b/docs/community/aoc.html
@@ -32,7 +32,7 @@
 <a href="https://github.com/Camto/Advent-of-Code-2021/tree/master/BQN">Benjamin Applegate</a></p>
 </center>
 
-<p>Below, problems solved in BQN are shown in green, and problems solved in other languages in dark red.</p>
+<p>Below, problems solved in BQN are shown in green, and problems solved in other languages in faint red.</p>
 <svg viewBox='-20 -5 638 462'>
   <g stroke-width='1' font-size='14px' fill='currentColor'>
     <rect class='code' stroke-width='1' rx='6' x='0' y='0' width='598' height='452'/>
@@ -152,3 +152,4 @@
 <p>Just how okay is BQN? Hannu makes a case for optimism in <a href="https://hannuhartikainen.fi/blog/advent-of-bqn/">this blog post</a>. Hannu writes that BQN's slogan &quot;might be the best [further glowing praise/context]&quot;, in stark contrast to that time <a href="https://adspthepodcast.com/2021/12/17/Episode-56.html">Bryce and Conor agreed</a> that it was a bad slogan. And Andrey offers <a href="https://news.ycombinator.com/item?id=29521264">suspiciously positive comments</a> as well. The list includes &quot;good text editor support&quot;, but Johnny remarked on the forums that he didn't manage a good editor/REPL setup—a second contradiction, meaning that I can now prove the Riemann hypothesis in <em>two</em> independent ways. Johnny also cited little support for string handling and low-information error messages as obstacles. I like that these aren't tied to the core language, and can eventually be improved, even though it won't be easy. dzaima complained about frequent confusion between functions and immediate blocks, and right-to-left folds being the much less useful direction. I dislike that dzaima is right a lot.</p>
 <p>All three non-dzaimas of the last paragraph are essentially array outsiders, with little or no experience with languages like J or APL. In fact I think this describes the majority of Adventurers in BQN (although the list also includes array junkies like Raghu and Leah, and they've predictably made it further than most participants). Reaching out to a general programming audience wasn't initially a goal of BQN because I didn't think it <em>was</em> within reach. I realized this was wrong, and began to adjust course, in the early days, but am pleased to continue getting even more wrong.</p>
 <p>With all this said, a handful of reports about recreational programming is a pretty poor basis for judging a programming language. Advent of Code was more useful as a checkup on BQN and its environment, resulting in fixes to documentation and implementation. And dzaima improved various aspects of performance as a way to cheat in speed battles with ngn/k.</p>
+<p>BQN did do okay in terms of performance. At times programmers on the forum commented about having slow solutions (tens of seconds) or having to rewrite an obviously unsatisfactory algorithm. I don't think anyone mentioned having to switch languages for performance reasons, which is good news for an implementation as young as CBQN. But also not a surprise, as it's pretty fast with scalar code for an interpreter: about 10 times slower than C when I've measured it. Array code is usually faster, but can be slower. A particular problem was that in-place mutation <code><span class='Modifier2'>⌾</span><span class='Paren'>(</span><span class='Value'>i</span><span class='Modifier2'>⊸</span><span class='Function'>⊑</span><span class='Paren'>)</span></code> is only fast for very simple cases. Of course, this problem only arises because BQN's arrays are immutable, highlighting that immutable arrays, despite being perfect in every way, can be a pain. In a serious application you might be willing to endure more pain and use a mutable array object, to ensure good performance.</p>