hey, so i have kind of a dumb question

i’m using boot watch to reload files

but it only really works for cljs

is that expected, that the clj side of things won’t reload on watch?

how do you expect it to reload?

restart the whole application?

or just recompile the code?

some changes can be recompiled to get the effect, some cannot

so usually it's up to the user to specify how and when you want to get the backend code reloaded

well i think recompiling would be ok

atm i change a function and nothing at all happens

i can’t even stick in a prn to debug without waiting for a 70s+ boot command 😕

@dm3 i think i’m missing something very basic 😉

I usually recompile stateless things directly from the editor as I work

emacs/vim/Intellij support connecting the editor to the nRepl process

hmm, but it’s a web server

after changing something that is not recompileable, e.g. types that are part of a running application state

or things that got captured in the application state

I usually clojure.tools.namespace.repl/refresh-all

which computes the namespace dependency graph and reloads all of the namespaces where the dependencies got modified

see https://github.com/boot-clj/boot/wiki/Repl-reloading

i’ve been following the instructions at https://github.com/boot-clj/boot/wiki/Repl-reloading

for the repl

does that work with the code the web server would be using too?

i’ve just been pasting (repl/refresh) into the repl as needed so far

been using https://github.com/pandeiro/boot-http for serving stuff

i suppose i’m confused because my boot task is like (comp (watch) (serve …)) so i had thought the watch would “re-serve"

but it doesn’t work that way

wait, i have an idea, lol

no, i don’t think that worked

not sure about serve

@dm3 i think i figured it out

and i think it was very basic

the serve task has a :reload true option

yup, i wasted a loooot of time not having that turned on 😕

ok, next dumb q

when i do this

time env BOOT_JVM_OPTIONS="-client -Xmx2g -Xverify:none -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled" boot -h

as per https://github.com/boot-clj/boot/wiki/Improving-startup-time

i see a speedup for boot

but when i put BOOT_JVM_OPTIONS="-client -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Xmx2g -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -Xverify:none”

into boot.properties nothing happens

where are the boot.properties?

also you don't need the quotes in the properties file

well the file worked for other things, like BOOT_EMIT_TARGET

nm

https://github.com/boot-clj/boot/wiki/Configuring-Boot#note-about-boot_jvm_options

also, is it normal that compiling cljs without any optimisations takes ~30 seconds?

depends on how much cljs you've got

does 30 seconds include Clojure startup time?

it’s from the point boot says Compiling ClojureScript…

the whole thing from boot dev to something i can load in the browser is more like 70s

i’ve got maybe 1700 LOC in cljs

+ some libs

@thedavidmeister yes, 30-70s is possible if it's a clojurescript project how fast can this project start for you (after the deps has already been downloaded)? https://github.com/addplus/hoplon-ui-reload-example

i’ll check

i just get errors for that repo @onetom

why are you pasting pictures instead of just text?

the text is very long

ah, sorry, i forgot hoplon-ui is not in clojars yet. here is a similar repo which is good for benchmarking: https://github.com/onetom/boot-reloadable-hoplon

slack collapses text anyway and it takes less bandwidth to receive it.

ok, 22 seconds

20-30s

pair@dusty ~/g/o/boot-reloadable-hoplon> time boot dev
Starting reload server on 
Writing adzerk/boot_reload/init3346.cljs to connect to ...

Starting file watcher (CTRL-C to quit)...

Writing HTML files...
• index.html
Adding :require adzerk.boot-reload.init3346 to index.html.cljs.edn...
Compiling ClojureScript...
• index.html.js
Starting Vert.x on port 8000...
Elapsed time: 19.989 sec

^C
Stopping Vert.x on port 8000...
       32.18 real        73.49 user         3.40 sys

titdm:boot-reloadable-hoplon thedavidmeister$ time boot dev
Starting reload server on 
Writing adzerk/boot_reload/init3306.cljs to connect to ...

Starting file watcher (CTRL-C to quit)...

Writing HTML files...
• index.html
Adding :require adzerk.boot-reload.init3306 to index.html.cljs.edn...
Compiling ClojureScript...
• index.html.js
Starting Vert.x on port 8000...
^C
Stopping Vert.x on port 8000...

real	0m26.508s
user	1m34.580s
sys	0m3.406s

Processor Name: Intel Core i5 Processor Speed: 2.7 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 16 GB

what helps with any bigger apps is the parallel compilation option

yeah i turned that on

but i still get this 😞

Starting reload server on 
Writing boot_reload.cljs...

Starting file watcher (CTRL-C to quit)...

Started HTTP Kit on 
Compiling Hoplon pages...
• index.cljs.hl
Adding :require adzerk.boot-reload to index.html.cljs.edn...
Compiling ClojureScript...
• index.html.js
Writing target dir(s)...
Elapsed time: 59.284 sec

^C
real	1m23.689s
user	1m49.179s
sys	0m5.921s

why are you writing to the target dir?

you only need that when you are preparing a deployment artifact

also, do you have an ssd? 🙂

also notice that you are starting both the frontend and the backend probably, so you load (and compile) a lot more libraries

mmk

shaved about 10s

Starting file watcher (CTRL-C to quit)...

Started HTTP Kit on 
Compiling Hoplon pages...
• index.cljs.hl
Compiling ClojureScript...
• index.html.js
Elapsed time: 54.853 sec

^C
real	1m14.745s
user	1m43.203s
sys	0m5.179s

also yeah, ssd 🙂

this is how i’m doing cljs

(cljs :optimizations :none
          :compiler-options { :parallel-build true
                              :cache-analysis true})))

well, I've never even timed how long my projects take to start

because it happens just a couple times a week

well i think it will happen to me less now actually

now that i found that :reload true option to get the backend to reload

Also if I use all those advance startup time saving options, I actually get the following:

pair@dusty ~/g/o/boot-reloadable-hoplon> time env BOOT_JVM_OPTIONS="-client -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -Xmx2g -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -Xverify:none" boot dev
Starting reload server on 
Writing adzerk/boot_reload/init3346.cljs to connect to ...

Starting file watcher (CTRL-C to quit)...

Writing HTML files...
• index.html
Adding :require adzerk.boot-reload.init3346 to index.html.cljs.edn...
Compiling ClojureScript...
• index.html.js
Starting Vert.x on port 8000...
Elapsed time: 13.981 sec

^C
Stopping Vert.x on port 8000...
       20.23 real        28.71 user         1.70 sys

i only use this though:

pair@dusty ~/g/o/boot-reloadable-hoplon> echo $BOOT_JVM_OPTIONS
-Xmx2g -Xverify:none

yeah i have all the things turned on

yep, I'd alias the params under something like alias boot-dev=env BOOT_JVM_OPTIONS...

because the incremental compile can get optimized over time and gives us around 1second re-compile times

if i have those startup time optimizations, my incremental compile time doesn't go below 1.5-1.8s

which is just enough to feel uncomfortable with it

my incremental compile is like 3-4s

that sounds sluggish...

yes, my cljs is really slow

btw, the :cache-analysis true doesn't seem to affect the performance unfortunately

any other things i can tweak?

you should try this vertx based server too, using the boot-static package, but that would assume you have your backend served separately

for that im still using boot-jetty

what the spec of your processor?

also you pressed Ctrl-C too early in your example. you should wait until the Elapsed time: ... appears

can you check your cache sizes too in the system report, pls?

ah i see, so you can have one boot task to fire up the backend and one to handle cljs?

also with 8GB ram i can imagine that you might max that out and your cljs compilation process is forced to do swapping...

@thedavidmeister exactly

Processor Name:	Intel Core i7
  Processor Speed:	2.6 GHz
  Number of Processors:	1
  Total Number of Cores:	4
  L2 Cache (per Core):	256 KB
  L3 Cache:	6 MB
  Memory:	8 GB

pair@dusty ~/a/be> time boot dev
nREPL server started on port 63750 on host 127.0.0.1 - 

Starting file watcher (CTRL-C to quit)...

Starting #'sys/dev
Elapsed time: 1.604 sec

^C       17.02 real        43.73 user         1.53 sys

and my recompile + reload times are like this:

#'sys/dev:refreshing
Unloading: (app.profile-test app.users-test app.core-test app.schema-test sys app.schema app.core app.users)
Reloading: (app.users app.core app.schema sys app.schema-test app.core-test app.users-test app.profile-test)
Elapsed time: 0.689 sec

which is actually slow because those *-test namespaces shouldn't even be reloaded really i think...

hmm ok

Independent Deployability FTW as Uncle Bob would say 🙂

would that be ok if i use sente?

now, that i don't know 🙂

imean it should work of course but i haven't tried it myself yet

aight, i guess i’ll put some more tickets up

thanks for the help

anything to get these load times down is useful

it is getting to the point where it’s getting in the way

so i don't know what the pitfalls would be. in case of using castra, i had to specifically use [jumblerg/ring.middleware.cors "1.0.1"] for the CORS support

also that backend reloading is implemented by the stuart sierra REPL flow which im using via danielsz/boot-system

the problem i found with panderios/boot-http is the it's just using the jetty server built-in reload functionality, which is only triggered during serving a request

which means that request is still served by the old code

so you are experiencing an earlier version than your latest change

oh

which is fucking misleading of course...

that is annoying

so its always one behind?

so i switched to

<dependency>
            <groupId>tailrecursion</groupId>
            <artifactId>boot-jetty</artifactId>
            <version>0.1.3</version>
            <scope>compile</scope>
        </dependency>

yes, it was always behind. it might have been an old bug but at that time it seemed like an architectural issue of boot-http

well until tonight i’ve had to re-run boot dev for every change

and wait a 1:20

so even being one behind is an upgrade >.<

until you waste an hour because of it, then you just negated that gain 😜

well even saving 10s here and there helps my sanity

but then again, i don't have a better recommendation than using boot-system which would require a serious rehaul of the app using https://github.com/tolitius/mount might be better but im yet to figure out how can it form a coherent flow with intellij....

also my recommendation is to get the fastest possible machine you can possibly purchase with at least 16GB ram

i’m just using atom

it should pay back fast...

i’m not actually making any money off my app yet, so...

if i get some customers one day i will 🙂

you mean u don't have any other source of income for an upgrade?

oh, i literally just moved house

and have a huge backlog of shit to buy for the apartment

like a faster machine? ... ;-/

:))

haha, somewhere on the list

i’m going to start with “kitchen table"

and “bed"

before “another 8gb of ram"

fuck the curtains and carpet...

that can wait

skewed priorities... 🙂

lol, my gf is getting an upgrade before me

can you imagine, she’s trying to compile this stuff on an air

it just doesn’t really happen

see you can get a kitchen table with 1GB ram first, so you get another 8GB into your computer instead and only then upgrade your kitchen table 😉

maybe you should upgrade your girlfriend instead 😉

well we had an imac at the last place, that was ok

but there’s just nowhere to put it here

we’ll get there

aw... 🙂

anyway, i g2g

getting late here

thanks again for the help