Fork me on GitHub
#clojurescript
<
2019-10-01
>
flyboarder00:10:05

A recent thing I started working on, looking for other suggestions that would possibly evolve to es6 class being actually generated

Mikko Harju05:10:11

Hi! Any ideas why CLJS compiler takes a long time to compile after a changed file in Figwheel-Main? The same project with lein-figwheel and lein-cljsbuild is at least 3 times faster. The initial build takes 37 seconds and after changing just one file, the recompilation takes 30 seconds. With the latter setup, it’s under 10 seconds. I’ve tried using aot-cache: true, and npm-deps: false (this was some time ago a problem since I have a node_modules alongside the project that I’m not using in CLJS side, but for UI test automation).

Mikko Harju05:10:34

^{:css-dirs ["resources/public/css"]
  :ring-handler filippos.app-server/handler
  :watch-dirs ["src" "env/dev/cljs"]}
{
 :aot-cache       true
 :output-dir      "resources/public/js/out"
 :output-to       "resources/public/js/app.js"
 :main            filippos.dev
 :asset-path      "js/out"
 :source-map      true
 :optimizations   :none
 :pretty-print    true
 :closure-defines {"re_frame.trace.trace_enabled_QMARK_" true
                   "day8.re_frame.tracing.trace_enabled_QMARK_"  true}
 :preloads        [day8.re-frame-10x.preload]
 :npm-deps        false
}
this is the compiler / figwheel-main configuration I’m currently using

Mikko Harju05:10:00

If I use verbose: true, after printing out the configuration map, it takes about 5 seconds for the first compilation message to appear, and then

Copying file:/.../src/filippos/inv/views/search.cljs to resources/public/js/out/filippos/inv/views/search.cljs
it stays the longes, after which it prints the compilation successful message.

Mikko Harju05:10:44

If I try the same with lein-figwheel and lein-cljsbuild (which I am now trying to transition this project to figwheel-main), I don’t get those messages when recompiling.

dnolen13:10:02

@mikko :verbose true :compiler-stats true will give you more information what's happening

Mikko Harju05:10:06

Thanks, I’ll take a look!

Mikko Harju06:10:09

Compiling src/filippos/foo.cljs to resources/public/js/out/filippos/foo.js, elapsed time: 43.218522 msecs
Compile sources, elapsed time: 3229.204762 msecs
Compile sources, elapsed time: 906.624457 msecs
Copying file:/.../src/filippos/foo.cljs to resources/public/js/out/filippos/foo.cljs
[Figwheel] Successfully compiled build app to "resources/public/js/app.js" in 29.783 seconds.
filippos.foo is a ns with no dependencies. It takes about 5 seconds to get to the compilation after printing out the configuration, and then the compilation stages take the given amount of time, after which there is a big delay between the copy phase and the success-message. It seems that figwheel-main does very little between the compilation start and finish message (basically invoking a build-fn that seems to be wrapping cljs.build.api/build @U050B88UR

Mikko Harju06:10:23

Just running cljs.build.api/build with same opts is fast, just basically

Compile sources, elapsed time: 25.342377 msecs
Compile sources, elapsed time: 732.973113 msecs

Mikko Harju06:10:24

Would this indicate there is some delay in the figwheel-main side?

dnolen11:10:07

dunno seems like a question for the #figwheel-main channel

Mikko Harju11:10:17

OK, I’ll try there. No one is yet to reply for my first question though. Thanks for input!

Mikko Harju12:10:44

@U050B88UR it seems that the culprit is https://github.com/bhauman/figwheel-core/blob/master/src/figwheel/core.cljc#L865 this swap takes the most amount of time, I don’t know if there is anything we can do about that one, since the compiler env is a very big map (takes tens of seconds to print out)

Mikko Harju12:10:13

So, maybe I’ll just let people know that they start evaluating changed fns to repl instead and be done with this 🙂 Thanks again for helping out!

dnolen12:10:07

swap! should take no time at all

dnolen12:10:55

there's very little chance that has much to do w/ it - if you can make a minimal project, open an issue

Mikko Harju13:10:11

@U050B88UR OK, I just checked this by putting println -statements before and after the swap! and there it was waiting for several seconds until it printed out that it was completed… so not very scientific to say the least 😄

dnolen13:10:01

probably a red herring - what JVM settings are you using?

dnolen13:10:13

GC init / max heap size is often improtant

Mikko Harju13:10:33

compilation done. swap compiler env.
"Elapsed time: 11949.210127 msecs"
Swap done. Return result.

Mikko Harju13:10:50

That elapsed time was (time (swap! ….))

Mikko Harju13:10:59

I’m using default JVM settings

Mikko Harju13:10:45

Increased -Xmx and -Xms to 4g and -Xmn to 2g it seemed to have no effect? @U050B88UR

Mikko Harju13:10:10

Culprit is the update function inside the swap!

(merge (select-keys x [:started])
                             @local-data
                             (cond-> {:finished (System/currentTimeMillis)}
                               (some? changed-files) ;; accept empty list here
                               (assoc :changed-files changed-files)))
if I replace that with identity, swap! drops to 0.366281 msecs

Mikko Harju13:10:58

Maybe by tweaking that should do the trick, then.

dnolen13:10:48

right I'm skeptical still because the only way swap could take a long time is if there was a lot of contention

dnolen13:10:54

are you using :parallel-build?

Mikko Harju13:10:17

I’ve been using it and not using it, it seems to be making no difference in total time

Mikko Harju13:10:11

I’ll try to put it off now and see what happens

Mikko Harju14:10:54

Without :parallel-build it’s “Elapsed time: 10860.778534 msecs”

Mikko Harju14:10:01

So about the same as with it.

Mikko Harju14:10:30

Strange. Now after a few evaluations it dropped to under a second

Mikko Harju14:10:54

I’ve seen this before, so the first “watch” recompilation takes around 30 seconds, after which they take around 14 seconds, which is still about twice as much as with lein-figwheel.

lilactown14:10:47

@mikko my first guess is :recompile-dependents might be different between your lein-cljsbuild config and figwheel-main config

Mikko Harju05:10:31

Thanks! I have explicitly tried to set :recompile-dependents to false but it did not seem to help.

papachan14:10:20

dont remember the explanation about this in clojurescript:

(if (not= js/NaN js/NaN)
    (.log js/console "not equal"))

papachan14:10:27

maybe is the same in js?

mfikes14:10:52

@papachan ClojureScript doesn't change the equality semantics of js/NaN. (By the way, there is a literal for that value: ##NaN)

papachan15:10:46

Thanks! Will have a look

lilactown15:10:09

in modern engines, I believe js/Number.isNaN is the way to go

lilactown15:10:03

note that Number.isNaN is different than the global isNaN 😰

lilactown15:10:44

isNaN("I'm not a number") === true Number.isNaN("I'm not a number") === false

😭 4
papachan16:10:26

@U4YGF4NGM got it ! thank you !

roklenarcic15:10:27

I'm using Timbre for logging in cljs, and I'm wondering if I can pass a js/Error to the log function somehow and get that stack trace logged. Currently when I log errors with timbre it shows me the stack trace of timbre log function instead of the error I gave to it.

borkdude15:10:44

@roklenarcic there's a #timbre channel as well

borkdude15:10:11

and FWIW, you can just try it out I guess 🙂

jpmonettas20:10:19

hi everybody, I'm trying to create a issue for clojurescript (has to do with cljs.reader) but I can't login to JIRA with google, says my account is not authorized, anybody knows what am I doing wrong?

Alex Miller (Clojure team)20:10:49

please file an issue on https://ask.clojure.org and tag it as "problem" - it can be triaged there and we'll create a ticket if needed