Analyze and improve the performance of Import/export resolution

[Akirathan]

Related to #9235. Benchmark introduced in #9158.

The following benchmark:

sbt:runtime-benchmarks> benchOnly org.enso.compiler.benchmarks.module.ImportStandardLibrariesBenchmark

measure mostly the performance of import/export resolution, as this screenshot suggests:

[JaroslavTulach]

While this PR started as a request to speed up a benchmark, I did a real profiling of ./runner (generated by native image from #9997). While executing ./runner --run test/Base_Tests ^Text I see more than a second spend in the import/export resolution:

Because this is native image, there is no JVM initialization overhead and this is a real cost of our algorithm. Note: There is a significant cost of GC, but that may be because we generate too much garbage somewhere.

How many imports we have? Few thousands? Why should it take to more than a second to process such a small amount of data?

Analyze

To analyze the data, download Oracle Developer Studio 12.6 and use its Analyzer. Download my experiment data. Unzip and open with:

$ PATH=/jdk8/bin:$PATH
$ /OracleDeveloperStudio12.6-linux-x86-bin/developerstudio12.6/bin/analyzer runTextTests.er/

flamegraphs view and find (top right corner) shall be your friends when exploring the gathered data.

Record

Rebuild ./runner executable with debug information on (otherwise the names methods wouldn't be visible):

diff --git build.sbt build.sbt
index 0be71a204a..18a5825c87 100644
--- build.sbt
+++ build.sbt
@@ -2432,9 +2432,9 @@ lazy val `engine-runner` = project
             "-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog",
             "-H:IncludeResources=.*Main.enso$",
             // useful perf & debug switches:
-            // "-g",
-            // "-H:+SourceLevelDebug",
-            // "-H:-DeleteLocalSymbols",
+            "-g",
+            "-H:+SourceLevelDebug",
+            "-H:-DeleteLocalSymbols",
             // you may need to set smallJdk := None to use following flags:
             // "--trace-class-initialization=org.enso.syntax2.Parser",
             "-Dnic=nic"

launch OracleDeveloperStudio12.6-linux-x86-bin/developerstudio12.6/bin/analyzer and choose to run an experiment. Specify ./runner as executable and add arguments. Run, save, analyze.

Btw. to speed working with NI up, it may make sense to comment out GraalPython:

diff --git project/GraalVM.scala project/GraalVM.scala
index 85c6124b76..56b8faea9b 100644
--- project/GraalVM.scala
+++ project/GraalVM.scala
@@ -109,7 +109,7 @@ object GraalVM {
     if (isEspressoMode()) {
       espressoPkgs
     } else {
-      jsPkgs ++ pythonPkgs
+      jsPkgs
     }
 
   private val allowedJavaVendors = Seq(

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-05-22):

Progress: - Conflicting extension methods closed by making sure the method resolution is deterministic - #9844

• Small fix fo --disable-private-check flag - Ensure disable private check cmd line option disables runtime private access checks #10034.
• Some DRY refactoring in runtime-integration-tests.
• Add a new benchmark that measures only imports resolution and imports+exports resolution, not anything else. It should be finished by 2024-05-28.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-05-23):

Progress: - Discovered the exact location of performance bottleneck - #10043 (comment)

• Before rewriting it, trying to understand what the code does, writing some discovery unit tests
• Opened PR for private methods in Implement private methods #10060
  • Parser changes are already in. It should be finished by 2024-05-28.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-05-27):

Progress: - Finally written some unit tests for exports resolution and symbol optimization

• Now, I will try to simplify the whole algorithm It should be finished by 2024-05-28.

[enso-bot]

Pavel Marek reports a new 🔴 DELAY for yesterday (2024-05-29):

Summary: There is 7 days delay in implementation of the Analyze and improve the performance of Import/export resolution (#9236) task.
It will cause 7 days delay for the delivery of this weekly plan.

Delay Cause: Got distracted by a lot of other issues. Still trying to simplify the algorithm.

[enso-bot]

Pavel Marek reports a new STANDUP for yesterday (2024-05-29):

Progress: - Refactoring of test utilities - move it into a separate project - #10112

• Impact of removing optimize symbol restrictions.
• Trying a rapid simplification of the algorithm. It should be finished by 2024-06-04.

[enso-bot]

Pavel Marek reports a new STANDUP for today (2024-05-31):

Progress: - Fighting hard with sbt - trying to disseminate syntax classes from runtime.jar and maybe even runner.jar and put it into a separate module? It should be finished by 2024-06-04.

[JaroslavTulach]

Do you know why sbt buildEngineDistribution takes so long, especially:

Generating index for built-distribution/enso-engine-0.0.0-dev-linux-amd64/enso-0.0.0-dev/lib/Standard/Table

This is the result of sampling:

14s in optimize!?

[Akirathan]

Closed by #10369