https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112019-06-12T12:56:11ZRuby Issue Tracking SystemRuby master - Feature #15881: Optimize deconstruct in pattern matchinghttps://bugs.ruby-lang.org/issues/15881?journal_id=784812019-06-12T12:56:11Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>I talked with ktsj, the author of pattern matching. He had actually considered caching the result of deconstruct, but we found it difficult because of some reasons.</p>
<ul>
<li>If destructive operation is applied to the object being matched (this is possible in a guard expression), the behavior of pattern matching would get messed up.</li>
<li>ktsj investigated Scala's pattern match, and it calls <code>unapply</code> method each time without caching.</li>
<li>We believe <code>Array#deconstruct</code> and <code>Hash#deconstruct_keys</code> would be most often called. They just return the receiver itself, so no object is generated. So, caching is useless in the typical case.</li>
<li>If the overhead of a method call itself matters, we can optimize it by adding a special instruction like <code>opt_deconstruct</code>.</li>
<li>If you need to cache the result of your own <code>deconstruct</code> definition, it is not so difficult to manually memoize the result.</li>
</ul> Ruby master - Feature #15881: Optimize deconstruct in pattern matchinghttps://bugs.ruby-lang.org/issues/15881?journal_id=784852019-06-12T13:23:18Zmarcandre (Marc-Andre Lafortune)marcandre-ruby-core@marc-andre.ca
<ul></ul><p>mame (Yusuke Endoh) wrote:</p>
<blockquote>
<p>I talked with ktsj, the author of pattern matching. He had actually considered caching the result of deconstruct, but we found it difficult because of some reasons.</p>
<ul>
<li>If destructive operation is applied to the object being matched (this is possible in a guard expression), the behavior of pattern matching would get messed up.</li>
</ul>
</blockquote>
<p>Is there a valid use case for this though? Seems more like an anti-pattern that is better not being supported at all.</p>
<blockquote>
<ul>
<li>ktsj investigated Scala's pattern match, and it calls <code>unapply</code> method each time without caching.</li>
</ul>
</blockquote>
<p>Interesting. Do we know if there a is good reason for that? Scala is in general faster than Ruby, so it might not matter as much there...</p>
<blockquote>
<ul>
<li>We believe <code>Array#deconstruct</code> and <code>Hash#deconstruct_keys</code> would be most often called. They just return the receiver itself, so no object is generated. So, caching is useless in the typical case.</li>
</ul>
</blockquote>
<p>Well, unless I'm mistaken, it would not be completely useless as it would avoid <code>send(:respond_to?, :deconstruct_keys)</code> and <code>send(:deconstruct_keys)</code>, but the main issue really is for user defined classes.</p>
<blockquote>
<ul>
<li>If you need to cache the result of your own <code>deconstruct</code> definition, it is not so difficult to manually memoize the result.</li>
</ul>
</blockquote>
<p>I disagree. You can't simply use <code>@cache ||= ...</code>, you need to invalidate <code>@cache</code> if any dependency of the <code>...</code> changes. That may be quite tricky. Let's remember:</p>
<pre><code>There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
</code></pre>
<p>I remain convinced that it would be better to cache this result.</p> Ruby master - Feature #15881: Optimize deconstruct in pattern matchinghttps://bugs.ruby-lang.org/issues/15881?journal_id=784952019-06-12T22:18:23Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>marcandre (Marc-Andre Lafortune) wrote:</p>
<blockquote>
<p>mame (Yusuke Endoh) wrote:</p>
<blockquote>
<p>I talked with ktsj, the author of pattern matching. He had actually considered caching the result of deconstruct, but we found it difficult because of some reasons.</p>
<ul>
<li>If destructive operation is applied to the object being matched (this is possible in a guard expression), the behavior of pattern matching would get messed up.</li>
</ul>
</blockquote>
<p>Is there a valid use case for this though? Seems more like an anti-pattern that is better not being supported at all.</p>
</blockquote>
<p>ktsj and I prefer simpleness and robustness to performance when we consider the design of Ruby language. In Ruby, optimization is not primary; it is good as long as it does not change the naive semantics. For example, if we disallow the redefinition of bulit-in methods including <code>Integer#+</code>, we can make the interpreter faster and can make the implementation much simpler. But we still allow and respect the redefinition.</p>
<p>In this case, more intelligent optimization (including nice cache invalidation) that does not affect the semantics is needed (if the performance is really needed).</p>
<blockquote>
<blockquote>
<ul>
<li>If you need to cache the result of your own <code>deconstruct</code> definition, it is not so difficult to manually memoize the result.</li>
</ul>
</blockquote>
<p>I disagree. You can't simply use <code>@cache ||= ...</code>, you need to invalidate <code>@cache</code> if any dependency of the <code>...</code> changes. That may be quite tricky. Let's remember:</p>
<pre><code>There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
</code></pre>
</blockquote>
<p>Agreed. The same goes to Ruby interpreter itself :-)</p> Ruby master - Feature #15881: Optimize deconstruct in pattern matchinghttps://bugs.ruby-lang.org/issues/15881?journal_id=785832019-06-14T23:41:12Zktsj (Kazuki Tsujimoto)kazuki@callcc.net
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/14912">Feature #14912</a>: Introduce pattern matching syntax</i> added</li></ul> Ruby master - Feature #15881: Optimize deconstruct in pattern matchinghttps://bugs.ruby-lang.org/issues/15881?journal_id=787892019-06-22T07:32:05ZEregon (Benoit Daloze)
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/78789/diff?detail_id=52208">diff</a>)</li></ul> Ruby master - Feature #15881: Optimize deconstruct in pattern matchinghttps://bugs.ruby-lang.org/issues/15881?journal_id=801812019-07-29T08:12:53Zko1 (Koichi Sasada)
<ul><li><strong>Assignee</strong> set to <i>ktsj (Kazuki Tsujimoto)</i></li></ul> Ruby master - Feature #15881: Optimize deconstruct in pattern matchinghttps://bugs.ruby-lang.org/issues/15881?journal_id=833902019-12-25T04:28:55Znaruse (Yui NARUSE)naruse@airemix.jp
<ul><li><strong>Target version</strong> deleted (<del><i>2.7</i></del>)</li></ul>