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 clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.
