Support for :none compilation (see #32)

[magomimmo]

Hi Chas, it would be great to have the support for the :none compilation during development. Its recompilation time with cljs-build auto is amazingly fast, while any other compilation mode is very slow due to the Google Closure Compiler involvement.

For people adopting a TDD workflow the missing support for the :none compilation option could be annoying (the same for the missing support for lein cljs-build test auto subtask).

Is it something you're thinking about?

Thanks

[cemerick]

This would require the test runner to locate the Google Closure library and either place it relative to the output of :none or alter the load path of the environment being used for testing so that it can be found. I personally have no desire to wire something like that up.

Is e.g. :whitespace so slow w/ cljsbuild auto? It should be nearly as fast as :none, as it's not much more than a dependency-order concatenation of :none's inputs.

[magomimmo]

Try this:

lein new cljs-start ws-perf
cd ws-perf
lein cljsbuild auto

The above compilation triggers the :dev profile in the profiles.clj file which uses the :whitespace option.
Then open the core.cljs, make a change and save it to trigger the auto recompilation.

Or I'm very wrong in the profiles.clj either 7'' (on my old iMac) is too much for a TDD workflow (and you still have to manually run the lein cljsbuild test command).

[cemerick]

Here are the timings I'm seeing running cljsbuild auto with clojurescript.test:

Compiling "target/cljs/whitespace.js" from ["src" "test"]...
Successfully compiled "target/cljs/whitespace.js" in 0.744474059 seconds.
Compiling "target/cljs/simple.js" from ["src" "test"]...
Successfully compiled "target/cljs/simple.js" in 1.968499665 seconds.
Compiling "target/cljs/advanced.js" from ["src" "test"]...
Successfully compiled "target/cljs/advanced.js" in 4.352611592 seconds.

Granted, it's a very small project, but auto recompilation should only end up touching the files that have actually been changed, which is surely the common case when editing with auto? < 1s for :whitespace seems quite reasonable.

[magomimmo]

Could you point to the repo? It's not impossible that in my cljs-start project there is something not working as I expect, because my numbers are totally different (I'm on very old imac at the moment).

[cemerick]

Those timings are from using cljsbuild auto on this repo, https://github.com/cemerick/clojurescript.test.

[magomimmo]

Hi Chas, I got the change to make few comparisons.
The slow compilation time of any compiler option but :none is shown only if you habilitate source map.
So the question could become: is source-map important enough during development in general and in a TDD cycle in specific to sacrifices for it the development cycle performance?

On Jan 26, 2014, at 2:14 PM, Chas Emerick notifications@github.com wrote:

Those timings are from using cljsbuild auto on this repo, https://github.com/cemerick/clojurescript.test.

—
Reply to this email directly or view it on GitHub.

[cemerick]

OK, that makes sense.

Source maps are certainly optional. I don't know what utility they would have in a "TDD" use case, since source maps are only (AFAIK) used when debugging. FWIW, they're enabled by default in piggieback/Austin, but then REPLs are not subject to the performance considerations of cljsbuild auto.

That said, I don't practice TDD, so I can't say what might be important to those that do…

Closing this now that we have an explanation of the perf differential.

[magomimmo]

Sure. I agree.

Inviato da iPad
Scusate gli errori d'ortografia

On 26/gen/2014, at 17:29, Chas Emerick notifications@github.com wrote:

OK, that makes sense.

Source maps are certainly optional. I don't know what utility they would have in a "TDD" use case, since source maps are only (AFAIK) used when debugging. FWIW, they're enabled by default in piggieback/Austin, but then REPLs are not subject to the performance considerations of cljsbuild auto.

That said, I don't practice TDD, so I can't say what might be important to those that do…

Closing this now that we have an explanation of the perf differential.

—
Reply to this email directly or view it on GitHub.