Thanks very much for the ideas!
We are currently using {:optimizations :simple} for this build. All of the
times I quoted above excluded the optimization time, however (I could see the
compile time due to :verbose + :compiler-stats). We're in the process of
switching to {:optimizations :whitespace} (we were looking at :none, but we
need to generate a single file, since this is for a React Native project).
> It would help if you could share your build config.
Good point! Here is the cljsbuild build
:ci {:source-paths ["src" "src-ios" "test" "test-ios"]
:warning-handlers [foo.cljsbuild-util/fail-on-warning]
:compiler {:output-to "ios/foo/main.jsbundle"
:parallel-build false
:output-dir "target/ci/"
:optimizations :simple ; <- we're in the process of changing this to
"whitespace"
;; Rules for pulling in RN bundle
:closure-extra-annotations ["generated" "internal"]
:closure-defines {"foo.app.config.foo_host" ""
"foo.app.config.test_QMARK_" true}
:language-in :ecmascript5
:foreign-libs [{:file "../build/react-native-dev.js"
:provides ["react-native"]}
{:file "../build/react-requires-dev.js"
:provides ["react-requires"]}]
:externs ["externs.js"]
:verbose true
:compiler-stats true}}
and our lein profile is
:ci {:env {:test-multiplier "0.5"} ; environ variable
:jvm-opts ^:replace ["-Xms1024m" "-Xmx1024m" "-server" "-Xss2m"]
I was unaware of shadow-build - thanks for the idea! I'll take a look.
Ben
On Saturday, February 11, 2017 at 1:26:36 AM UTC-7, Thomas Heller wrote:
> Are you by any chance using anything other than {:optimizations :none} in
> your dev build config? 12s seems a bit excessive if you are just doing CLJS
> recompiles.
>
> Ensure that your dev build does not use any production build settings. Your
> CI server should probably run in production mode though as 12s shouldn't hurt
> that much there. Typically when it comes to building larger projects you want
> to rely on :none with caching for development. It would help if you could
> share your build config.
>
>
> If you are feeling adventurous you could try shadow-build if only to get a
> more detailed report on where the time is spent. It should be a bit faster
> overall as well but not by much. Happy to walk you through an example if you
> want to test it.
>
> /thomas
>
> On Friday, February 10, 2017 at 6:15:34 PM UTC+1, Ben Brinckerhoff wrote:
> > First of all, thanks to everyone for their hard work on Clojurescript and
> > related tooling. It’s an incredibly productive and reliable stack to use.
> >
> > I’m investigating ways to speed up compile times for a closed-source
> > project. We have about 8000 Clojurescript LOC and 200 Clojure LOC (in src
> > and test combined). Some very rough indicators: a fresh compile of our test
> > build takes about 60s. A small change to a file with maybe 15 reverse
> > dependencies takes about 12s using `cljsbuild auto`. We are using
> > lein-cljsbuild 1.1.4 and clojurescript “1.9.293”.
> >
> > These times are pretty good, but of course speeding up compiles shrinks our
> > feedback loop, both locally and on CI, where we do a number of fresh
> > compiles for different builds. As a result, we want to see if there are
> > things we can do to our code to speed up compiles.
> >
> > We have turned on the `verbose` and `compiler-stats` flags so we can see
> > more information about compile times. We hope to upgrade to 1.9.456 soon so
> > we can see per-file compile stats. We also need to investigate parallel
> > builds again - we had previously run into bugs here, but I didn’t take the
> > time to investigate more fully.
> >
> > Besides total LOC, are there other aspects of code bases that are known to
> > slow down compiles? Perhaps macro expansion (we have a lot of core.async
> > `go` blocks in some namespaces)? Perhaps the complexity of the dependency
> > graph between namespaces? Something else? Has anyone else had experience
> > altering a CLJS code base to improve compile times? Or tweaking compiler
> > flags? `optimization` makes a big difference of course, but for my current
> > investigation, I'm ignoring optimization time.
> >
> > Also, I noticed that Clojurescript performance is an idea for the Google
> > Summer of Code
> > https://github.com/clojars/clojure-gsoc-2017/blob/master/project-ideas.md#clojurescript-performance
> >
> > “There are many impactful enhancements we would like to make to
> > ClojureScript with respect to both runtime and compile time performance …
> > For compile time enhancements we should examine where parallelization, AST
> > data representation changes, or more aggressive caching of intermediate
> > artifacts may deliver faster development and production build time.”
> >
> > I did a quick search of Clojurescript for perf issues on JIRA, but didn’t
> > see anything related to these (apologies if I just missed something
> > obvious!). Is there a list somewhere of open issues that might improve perf
> > in the compiler? Or are those ideas mostly in the “needs investigation”
> > stage?
> >
> > Thanks very much!
> > Ben
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/clojurescript.
