<div dir="ltr">I guess the blame is mine, and I agree that "feature" is questionable.<div><br><div>The idea was that the cache should behave as the non-cached variant</div><div>as much as possible. And in the non-cached variant the whole code path is</div>
</div><div>searched and the cache could be updated as well.</div><div><br></div><div>Since the patch is trivial, can you add it and we will bring up to discussion internally </div><div>and here if someone has an opinion.</div>
<div><br></div><div>/Dan</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 19, 2013 at 12:49 PM, José Valim <span dir="ltr"><<a href="mailto:jose.valim@plataformatec.com.br" target="_blank">jose.valim@plataformatec.com.br</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello OTP team,<div><br></div><div>I was experimenting with Erlang's code path cache and I have found that some operations actually become quite slower when the code path cache is enabled.</div>
<div>In particular, code:ensure_loaded/1 becomes an order of magnitude slower when the module is not loaded and does not exist in any code path.</div>

<div><br></div><div>By inspecting the code_server source code, I have noticed that this line is responsible for the slow down:</div><div><br></div><div><a href="https://github.com/erlang/otp/blob/fb0006c937e284cefe5217d4c2a4b45ff7dfb758/lib/kernel/src/code_server.erl#L1341" target="_blank">https://github.com/erlang/otp/blob/fb0006c937e284cefe5217d4c2a4b45ff7dfb758/lib/kernel/src/code_server.erl#L1341</a></div>


<div><br></div><div>Basically, every time we can't find a module, the whole code path is rehashed. The slow down will be even bigger for larger code paths.</div><div><br></div><div>I tried blaming the line above with no success. Removing the line also does not introduce failures into the code_SUITE so I am unsure if this behaviour is by design or not. The only use case I can think for this behaviour is to be able to load beam files that are added to code paths *after* the code path was added to the code server but it seems an arguable behaviour considering its effects on a module miss.</div>


<div><br></div><div>I may be missing something obvious that justifies the current behaviour and, if so, I believe we should at least document it. I will be glad to send a patch if the OTP team agrees with it.</div><span class="HOEnZb"><font color="#888888"><div>
<div>

<div><br></div><div><br></div><div><span style="font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b>José Valim</b></span></div><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><div>


<span style="font-family:verdana,sans-serif;font-size:x-small"><a href="http://www.plataformatec.com.br/" style="color:rgb(42,93,176)" target="_blank">www.plataformatec.com.br</a></span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Skype: jv.ptec</span></div>


<div><span style="font-family:verdana,sans-serif;font-size:x-small">Founder and Lead Developer</span></div></span></div></span></div></div>
</div></font></span></div>
<br>_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
<br></blockquote></div><br></div></div>