You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 4, 2022. It is now read-only.
If I pass in no classpath args to lumo, calling time on the build shows it takes ~500ms — good! But if to the lumo REPL I pass in even one path (in this case it was "/Users/alexandergunnarson/.m2/repository/org/clojure/spec.alpha/0.1.143/spec.alpha-0.1.143.jar") it takes ~1100ms. This appears to increase linearly with the number of paths in the classpath, according to experiments I did with both passing in classpath to lumo and changing the classpath dynamically via lumo.classpath/add!/lumo.classpath/remove!. For instance, if I pass in the actual, full classpath of a real project of mine (not just this test project) while only putting simple.cljs in the src folder, Lumo takes ~350 seconds to compile it which is kind of insane. By comparison, with the same dependencies and same single source file, cljsbuild compiles it in a few seconds or less (the reason it's not sub-second appears to be due to startup time).
Additionally, when I run lumo.build.api/watch and make a small edit to simple.cljs, the same latency happens every time it tries to recompile. I would have assumed it would have leveraged some sort of caching strategy and/or change awareness à la Figwheel; were this the case I could even live with an initial 350 second compilation time as long as subsequent recompilations were truly incremental (a second or less for a small change high up in the dependency graph).
I would have expected the compiler to be dependency-aware and know that simple.cljs does not depend on anything, even though there are many files in the classpath.
Let me know your thoughts about this issue, and how I can contribute to push this forward!
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
First of all, let me thank you for a job well done on Lumo! I'm really excited by the possibilities it brings to self-hosted compilation.
In my /src folder of a test project, I only have one file — let's call it simple.cljs — that looks like this:
I downloaded the Lumo source to experiment with and run
lumo
and then the following within the REPL:If I pass in no classpath args to
lumo
, callingtime
on the build shows it takes ~500ms — good! But if to thelumo
REPL I pass in even one path (in this case it was"/Users/alexandergunnarson/.m2/repository/org/clojure/spec.alpha/0.1.143/spec.alpha-0.1.143.jar"
) it takes ~1100ms. This appears to increase linearly with the number of paths in the classpath, according to experiments I did with both passing in classpath tolumo
and changing the classpath dynamically vialumo.classpath/add!
/lumo.classpath/remove!
. For instance, if I pass in the actual, full classpath of a real project of mine (not just this test project) while only putting simple.cljs in the src folder, Lumo takes ~350 seconds to compile it which is kind of insane. By comparison, with the same dependencies and same single source file, cljsbuild compiles it in a few seconds or less (the reason it's not sub-second appears to be due to startup time).Additionally, when I run
lumo.build.api/watch
and make a small edit to simple.cljs, the same latency happens every time it tries to recompile. I would have assumed it would have leveraged some sort of caching strategy and/or change awareness à la Figwheel; were this the case I could even live with an initial 350 second compilation time as long as subsequent recompilations were truly incremental (a second or less for a small change high up in the dependency graph).I would have expected the compiler to be dependency-aware and know that simple.cljs does not depend on anything, even though there are many files in the classpath.
Let me know your thoughts about this issue, and how I can contribute to push this forward!
The text was updated successfully, but these errors were encountered: