[erlang-bugs] Expensive module miss when code path cache is enabled

[Dan Gudmundsson]

I guess the blame is mine, and I agree that "feature" is questionable.

The idea was that the cache should behave as the non-cached variant
as much as possible. And in the non-cached variant the whole code path is
searched and the cache could be updated as well.

Since the patch is trivial, can you add it and we will bring up to
discussion internally
and here if someone has an opinion.

/Dan

On Tue, Nov 19, 2013 at 12:49 PM, José Valim <
jose.valim@REDACTED> wrote:

> Hello OTP team,
>
> 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.
> 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.
>
> By inspecting the code_server source code, I have noticed that this line
> is responsible for the slow down:
>
>
> https://github.com/erlang/otp/blob/fb0006c937e284cefe5217d4c2a4b45ff7dfb758/lib/kernel/src/code_server.erl#L1341
>
> 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.
>
> 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.
>
> 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.
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Lead Developer
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20131119/85c4849f/attachment.htm>