[JavaScript] slow performance of runtime, possibly due to code minimizer

[mint-thompson]

In my project, I recently updated the runtime dependency from version 4.9.3 to 4.13.0. Users reported slowed performance in the new version of our project. Running the node profiler showed that the majority of ticks were being used by antlr4. This is an excerpt from the node profiler report (directory names shortened for easier reading):

 [Bottom up (heavy) profile]:
  Note: percentage shows a share of a particular caller in the total
  amount of its parent calls.
  Callers occupying less than 1.0% are not shown.

   ticks parent  name
  204999   84.8%  <...>/.nvm/versions/node/v18.12.1/bin/node
  139105   67.9%    <...>/.nvm/versions/node/v18.12.1/bin/node
  48327   34.7%      LazyCompile: *t <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:13730
  39110   80.9%        LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:202512
  39093  100.0%          LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:201522
  35640   91.2%            LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:201522
   3446    8.8%            LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:200458
   5857   12.1%        LazyCompile: *u <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:189947
   3327   56.8%          LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:202512
   3324   99.9%            LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:201522
   2439   41.6%          LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:201522
   2439  100.0%            LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:201522
     79    1.3%          Function: ^value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:202512
     78   98.7%            LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:201522
      1    1.3%            Function: ^value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:201522
   3325    6.9%        LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:200458
   3228   97.1%          LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:199928
   3228  100.0%            LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:199125
     97    2.9%          Function: ^value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:199928
     94   96.9%            LazyCompile: *value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:199125
      3    3.1%            Function: ^value <...>/node_modules/antlr4/dist/antlr4.node.cjs:1:199125

Since the reported locations were in minimized code, I decided to rebuild the antlr4 dependency without minimizing it in order to more easily locate the causes of the slow performance. To do this, I modified webpack.config.js to not minify the code

// inserted at webpack.config.js:59
optimization: {
    minimize: false
}

After rebuilding antlr4, I re-ran my project with the node profiler using the same input, and I observed two things:

• the performance was much faster (43338 total ticks used by node), and
• antlr4 was not appearing at all near the top of the bottom-up profile.

I'm not an expert on webpack or code minimizers, but it appears that somehow, the minimization process is adversely affecting antlr4's performance. If it's acceptable, I think it could be useful to turn off minimization in order to restore performance of the JavaScript runtime. Alternatively, it may be possible that different webpack settings could be used to minimize the code while preserving performance.

I observed this behavior running Node 16 on Windows 10, and Node 18 on Linux (RHEL).

[ericvergnaud]

Please check #4323

[mint-thompson]

Please check #4323

Ah, this is perfect! Looks like things will be all sorted out in the next release. Thank you.

[mint-thompson]

Do you have an estimated release date for 4.13.1? This performance improvement is very important to my project.

[ericvergnaud]

No ETA but you could simply fork the runtime in the mean time