Analyze and improve the performance of inline compilation #9237
Comments
|
The reason for increasing timings - looks like we never reset scopes and (in short) |
|
Hubert Plociniczak reports a new STANDUP for the provided date (2024-03-21): Progress: Juggling between tasks. investigating inline execution problems in benchmarks. Tried to reproduce #9475, no success so far. Merged fix for #9278. It should be finished by 2024-03-22. Next Day: Next day I will be working on the #9237 task. Continue investigating benchmark issues. |
|
Hubert Plociniczak reports a new STANDUP for the provided date (2024-03-21): Progress: Juggling between tasks. investigating inline execution problems in benchmarks. Tried to reproduce #9475, no success so far. Merged fix for #9278. It should be finished by 2024-03-22. Next Day: Next day I will be working on the #9237 task. Continue investigating benchmark issues. |
|
Hubert Plociniczak reports a new STANDUP for the provided date (2024-03-22): Progress: PR that reduces one of the significant hotspots. Number of scopes continues to rise rather drastically, potentially leading to performance issues. CI build setup meeting. It should be finished by 2024-03-22. Next Day: Next day I will be working on the #9237 task. Continue investigating benchmark issues. |
|
Hubert Plociniczak reports a new 🔴 DELAY for yesterday (2024-03-25): Summary: There is 5 days delay in implementation of the Analyze and improve the performance of inline compilation (#9237) task. Delay Cause: Benchmark performance problems appear to be in the benchmark itself, hence the delay. Also juggling between different tasks. |
|
Hubert Plociniczak reports a new STANDUP for yesterday (2024-03-25): Progress: No luck with finding the solution so far, will need further work while juggling between tasks. Able to reproduce #9475 locally. It should be finished by 2024-03-27. Next Day: Next day I will be working on the #9237 task. Continue investigating benchmark issues. |
|
Hubert Plociniczak reports a new STANDUP for yesterday (2024-03-27): Progress: Reported on problems with patching for #9475. Would need more investigation if we want to go that path. Provided a fix for benchmark performance problems. It should be finished by 2024-03-27. Next Day: Next day I will be working on the #9237 task. Address review, pick up next item on the list. |
…rformance (#9520) As benchmarks show, a significant amount of time is spent traversing `Set` of `Graph.Link`s. That's unfortunate and unnecessary. We can equally keep helper maps that make search constant time. Fixed inline compilation benchmarks by properly cleaning up scopes after runs. Closes #9237. # Important Notes Things like   are all gone. There is plenty of it those are just samples. Benchmarks are back in order: ``` [info] # Warmup Iteration 1: 2.702 ms/op [info] # Warmup Iteration 2: 3.080 ms/op [info] # Warmup Iteration 3: 2.818 ms/op [info] # Warmup Iteration 4: 3.334 ms/op [info] # Warmup Iteration 5: 2.448 ms/op [info] # Warmup Iteration 6: 2.583 ms/op [info] Iteration 1: 2.908 ms/op [info] Iteration 2: 2.915 ms/op [info] Iteration 3: 2.774 ms/op [info] Iteration 4: 2.601 ms/op [info] Result "org.enso.compiler.benchmarks.inline.InlineCompilerBenchmark.longExpression": [info] 2.799 ±(99.9%) 0.953 ms/op [Average] [info] (min, avg, max) = (2.601, 2.799, 2.915), stdev = 0.148 [info] CI (99.9%): [1.846, 3.753] (assumes normal distribution) ```
github-project-automation
bot
moved this from 👁️ Code review
to 🟢 Accepted
in Issues Board
|
Hubert Plociniczak reports a new 🔴 DELAY for yesterday (2024-04-01): Summary: There is 4 days delay in implementation of the Analyze and improve the performance of inline compilation (#9237) task. Delay Cause: Got stuck debugging google analytics demo. |
Typo in bug number. Ignore |
Related to:
Benchmark added in #9158.
The benchmark
org.enso.compiler.benchmarks.inline.InlineCompilerBenchmark.longExpression(run withsbt:runtime-benchmarks> benchOnly org.enso.compiler.benchmarks.inline.InlineCompilerBenchmark.longExpression) measures the performance ofCompiler.runInline. As this method is used frequently by various instruments in the IDE, we would like to focus on it.This benchmark is a bit suspicious (unstable), as the very first sets of warmup iterations run faster than all the subsequent ones. Output of running the benchmark locally:
Attaching VisualVM and CPU sampler shows that most CPU time is consumed by AliasAnalysis, as expected:
Looking into memory usage of this benchmark, there does not seem to be any major leak.
The text was updated successfully, but these errors were encountered: