Speed Standard.Base initialization in simple Hello World example up!
#6100
Comments
JaroslavTulach
changed the title
.ir for module [local.Fib_Test.Arith] when just importing it
JaroslavTulach
changed the title
.ir for module [local.Fib_Test.Arith] when just importing it.ir for module [local.Fib_Test.Arith] when just importing
JaroslavTulach
changed the title
.ir for module [local.Fib_Test.Arith] when just importingStandard.Base initialization in simple Hello World example up!
|
The original title of this issue was "Avoid loading import Standard.Base.IO
main = [ IO, "Hello World!" ]or |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-10-25): Progress: - replacing
Next Day: Speeding up startup |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-10-26): Progress: -
Next Day: Speeding up startup |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-10-27): Progress: - Fixes and CI fighting and addressing comments in: #8160
Next Day: Speeding up startup
|
|
#8160 helps to speed up the IdeaOne way to address this is to split IR caches into structure and method bodies as method bodies aren't really needed until the method gets executed. That can be done with a diff --git engine/runtime/src/main/java/org/enso/compiler/ModuleCache.java engine/runtime/src/main/java/org/enso/compiler/ModuleCache.java
index c23790b688..b4122edece 100644
--- engine/runtime/src/main/java/org/enso/compiler/ModuleCache.java
+++ engine/runtime/src/main/java/org/enso/compiler/ModuleCache.java
@@ -161,6 +166,9 @@ public final class ModuleCache extends Cache<ModuleCache.CachedModule, ModuleCac
@Override
protected Object replaceObject(Object obj) throws IOException {
+ if (obj instanceof Expression) {
+ return null;
+ }
if (obj instanceof UUID) {
return null;
}This change lowers the size of body-less caches to If we read only the body-less part first, we should shorten the initial time to ImplementationEither we can have two private Map<Integer,Expression> pendingExpressions;
private int counter
...
if (obj instanceof Expression exp && counter >= 0) {
var refExpr = new RefExpression(++counter);
pendingExpressions.put(counter, exp);
return refExpr;
}store stream.counter = -1; // no more expression replaces
for (var entry : pendingExpressions.entrySet()) {
stream.writeInt(entry.getKey());
stream.writeObject(entry.getValue());
}the good thing is that all references among objects (mostly metadata) in the single stream are going to be shared between body-less part and expression bodies part. We just don't have to read the second part, when we are not interested in it. Reading the second part requires the |
|
Jaroslav Tulach reports a new STANDUP for the last Saturday (2023-10-28): Progress: - Integrated: #8160 (comment)
Next Day: Speeding up startup
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-10-30): Progress: - Integrated
Next Day: Speeding up startup |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-10-31): Progress: - Checking benchmarks & merging
Next Day: Speeding up startup |
|
The new idea is to store the Let's start with an analysis. By overriding the module cache reading code one can see that simple @@ -46,7 +50,14 @@ public final class ModuleCache extends Cache<ModuleCache.CachedModule, ModuleCac
@Override
protected CachedModule deserialize(EnsoContext context, byte[] data, Metadata meta, TruffleLogger logger) throws ClassNotFoundException, IOException, ClassNotFoundException {
- try (var stream = new ObjectInputStream(new ByteArrayInputStream(data))) {
+ try (var stream = new ObjectInputStream(new ByteArrayInputStream(data)) {
+ @Override
+ protected ObjectStreamClass readClassDescriptor() throws IOException, ClassNotFoundException {
+ var clazz = super.readClassDescriptor();
+ System.err.println("CLASS: " + clazz.getName());
+ return clazz;
+ }
+ }) {
if (stream.readObject() instanceof Module ir) {
try {
return new CachedModule(ir,CompilationStage.valueOf(meta.compilationStage()), module.getSource());here is the list: |
|
Jaroslav Tulach reports a new 🔴 DELAY for yesterday (2023-11-01): Summary: There is 10 days delay in implementation of the Speed There has been some progress, but more work is needed. Delay Cause: IR caches and import resolution is a complicated piece of our code base nobody wants to touch. I am moving forward, but slowly. Possible solutions: Yesterday I got new idea and started #8207 - I am thrilled now as I believe this direction has its merits. |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-11-01): Progress: -
Next Day: "on demand" IR caches
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-11-02): Progress: - "on demand" serde: a25bfb6
Next Day: "on demand" IR caches |
|
Jaroslav Tulach reports a new STANDUP for today (2023-11-03): Progress: - Investigating GraalVM for JDK21 update status: https://github.com/enso-org/enso/pull/7991/files#r1381210135
Next Day: "on demand" IR caches
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-11-08): Progress: - review of inline evaluation: https://discord.com/channels/@me/955430343308095518/1170940214991130654
Next Day: "on demand" IR caches
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-11-09): Progress: - IR persist everything: 5413e2f
Next Day: "on demand" IR caches
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-11-10): Progress: - able to write, read & use caches: #8207 (comment)
Next Day: "on demand" IR caches
|
|
Jaroslav Tulach reports a new 🔴 DELAY for the last Friday (2023-11-10): Summary: There is 7 days delay in implementation of the Speed Serialization & deserialization works, but we need to benefit from its possiblities. Delay Cause: Two holidays, one conference day. Changes in Possible solutions: The idea #8207 - seems to be working, but needs few more days. |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-11-12): Progress: - fixing broken CI build: 01e0d20
Next Day: "on demand" IR caches
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-11-13): Progress: - updating Frgaal 21: #8286
Next Day: "on demand" IR caches
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-11-14): Progress: - working on #8207
Next Day: "on demand" IR caches |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-11-15): Progress: - Found bug in
Next Day: "on demand" IR caches |
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-11-16): Progress: -
Next Day: "on demand" IR caches
|
|
Jaroslav Tulach reports a new STANDUP for yesterday (2023-11-17): Progress: - fixing license after Lookup library removal from runtime dependencies
Next Day: merge "on demand" IR caches |
|
There is 16% speed up of simple "hello world" application with the integration of: |
github-project-automation
bot
moved this from 👁️ Code review
to 🟢 Accepted
in Issues Board
#6062 introduced a testing infrastructure to allow us verify consistency of our IR caches more reliably. Now there is a time to use it and deliver some caching improvements. Enable additional check:
and make sure the
.irfile forArithmodule isn't read by storing the necessary information in caches.The text was updated successfully, but these errors were encountered: