更新（2020 年 3 月 2 日）

事实证明，我的示例中的编码以正确的方式构建，以摆脱 V8 JavaScript 引擎中已知的性能悬崖......

有关详细信息，请参阅bugs.chromium.org上的讨论。这个错误现在正在处理中，应该在不久的将来修复。

更新（2020 年 1 月 9 日）

我试图将下面描述的行为的编码隔离到一个单页 Web 应用程序中，但这样做时，行为消失了（??）。但是，下面描述的行为在完整应用程序的上下文中仍然存在。

也就是说，我已经优化了分形计算编码，这个问题在实时版本中不再是问题。如果有人感兴趣，这里仍然提供了显示此问题的 JavaScript 模块

概述

我刚刚完成了一个基于 Web 的小型应用程序，以比较基于浏览器的 JavaScript 与 Web Assembly 的性能。此应用程序计算 Mandelbrot Set 图像，然后当您将鼠标指针移到该图像上时，会动态计算相应的 Julia Set 并显示计算时间。

您可以在使用 JavaScript（按“j”）或 WebAssembly（按“w”）之间切换来执行计算和比较运行时。

单击此处查看正在运行的应用程序

然而，在编写这段代码时，我发现了一些出乎意料的奇怪的 JavaScript 性能行为......

问题总结

1. 这个问题似乎是 Chrome 和 Brave 中使用的 V8 JavaScript 引擎所特有的。在使用 SpiderMonkey (Firefox) 或 JavaScriptCore (Safari) 的浏览器中不会出现此问题。我无法在使用 Chakra 引擎的浏览器中对此进行测试

2. 此 Web 应用程序的所有 JavaScript 代码都已编写为ES6 模块

3. 我尝试使用传统function语法而不是新的 …

我遇到了Erlang OTP + Cowboy应用程序的问题,该应用程序不允许我同时打开足够的文件.

如何更改BEAM中允许的打开文件句柄数？

潜在地,我需要同时打开大约500个小文本文件,但似乎文件限制为224.我从这个小测试程序获得了224的值:

-module(test_fds).
-export([count/0]).

count() -> count(1, []).

count(N, Fds) ->
  case file:open(integer_to_list(N), [write]) of
    {ok, F} ->
      count(N+1, [F| Fds]);

    {error, Err} ->
      [ file:close(F) || F <- Fds ],
      delete(N-1),
      {Err, N}
  end.

delete(0) -> ok;
delete(N) -> 
  case file:delete(integer_to_list(N)) of
    ok         -> ok;
    {error, _} -> meh
  end,

delete(N-1).

这给了

$ erl
Erlang/OTP 20 [erts-9.2] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:10] [kernel-poll:false]

Eshell V9.2  (abort with ^G)
1> c(test_fds).     
{ok,test_fds}
2> test_fds:count().
{emfile,224}
3> …