Fork me on GitHub
#cljs-dev
<
2017-06-05
>
bensu04:06:13

Thanks @mfikes for the reminder. In summary, the pass was to replace all nodes with their respective records and that didn’t yield obvious improvements.

bensu04:06:29

but I didn’t realize then that there was a difference between using keywords and direct object access. When I say it like that it is rather obvious

mfikes11:06:58

OK. The difference between keywords and direct object access only appears to be, say, 10–20% faster in a microbenchmark I was doing. (When I said much faster above, I was mistaken.)

dnolen13:06:43

@mfikes sounds about right to me - while it may turn out switching records is useful, I suspect there’s still a few higher level gains to try first.

mfikes13:06:00

@dnolen Yeah, I’m becoming convinced that the optimizations to be found are likely high-level / algorithmic, rather than the low-level machinery surrounding persistent hashmap behavior

dnolen13:06:09

@mfikes another trick to try, run profiler on bootstrapped instead of JVM

mfikes13:06:30

Ahh… good point. I can see where the JavaScript is slow!

dnolen13:06:30

the performance profile across JS/JVM isn’t so different where this won’t be useful

dnolen14:06:08

@mfikes the flush thing looks interesting, was that like 5% thing or something?

dnolen14:06:53

would be nice to have observed perf benefit in the ticket / comments to give a bit more context

mfikes14:06:57

This is an example where it shows up near the top of the profile, but doesn’t really seem to make a huge difference in the overall observed time.

mfikes14:06:31

I’ll measure that one some more and see if it truly matters beyond an artifact of profiling.

dnolen14:06:42

k cool yeah

dnolen14:06:48

similarly in bootstrapped at least I did see 2 years ago that string concatenation dominates the profile - but to be expected

dnolen14:06:15

I think I played around with a couple of things - but I couldn’t find anything that really had any affect

andrewhr17:06:33

@mfikes there is any write up about profiling the compiler? #lazyweb here

mfikes17:06:48

I don’t think I personally have been using any techniques that are specific to the ClojureScript compiler. I generally run it on a large codebase with YourKit attached to it.

dpsutton17:06:48

i'm writing guides on how i setup CIDER and how to investigate things so that its hopefully easier to get other contributors

dpsutton17:06:29

just some static site. the hope is to get people used to how to test changes, feel comfortable navigating the codebase, the main functions and entry points, etc

dpsutton17:06:33

the hope is the lower barrier for newcomers to become committers the better

dnolen18:06:55

@andrewhr you can start up a JVM process (i.e. REPL), attach to it, then start your profile

mfikes19:06:22

One trick: Put a (Thread/sleep 30000) call prior to a call to cljs.build.api/build (as documented in https://clojurescript.org/guides/quick-start). This gives you time to attach a profiler and configure it for CPU measurements prior to it compiling your codebase.

shaunlebron19:06:30

@dnolen: do you manually upload cljs uberjars for each release? or is there an automated flow? (we are looking to do something similar for figwheel-sidecar)

dnolen19:06:01

@shaunlebron it’s manual, though could probably be automated

dnolen23:06:52

@anmonteiro #clojurescript conversation with @andrewboltachev got me thinking how hard it would be parameterize a dep like React to be pulled from NPM or cljsjs depending on what’s available - realizing that may be an artificial blocker for people trying this out more

anmonteiro23:06:55

@dnolen do you mean a runtime thing to know if we’re using :npm-deps or foreign?

dnolen23:06:20

just thinking it would be nice as a lib writer if I could not care how my downstream users wants to get the React dep

anmonteiro23:06:22

like, “I wanna use React, is it in js/React or do we have a React module?”

anmonteiro23:06:44

yeah I get it

dnolen23:06:45

I’m not thinking runtime actually - as that’s kind of annoying

dnolen23:06:03

I thinking more like shim ns which can get require the right thing depending on what’s available

anmonteiro23:06:04

I guess I shouldn’t say runtime

anmonteiro23:06:14

I was thinking of code emission

dnolen23:06:19

basically thinking about how to make this as easy as possible

dnolen23:06:26

since most users don’t even care about React at all

dnolen23:06:34

they just want Reagent/Rum/Om

dnolen23:06:42

and the occasional React component

dnolen23:06:55

basically :npm-deps is great if you starting greenfield on some React thing - but not if you’re a Reagent user and you don’t want to think about it

dnolen23:06:39

hrm yeah this could probably be solved at the artifact level

dnolen23:06:16

react.dep.node artifact with one namespace with the React stuff you can import , and react.dep.cljsjs which declares the same namespace

dnolen23:06:24

then you can control what you get with Maven

dnolen23:06:33

or something like this

dnolen23:06:35

might toy around with how practical that would be for Om to add this indirection

dnolen23:06:10

while it’s annoying to create artifacts just for this - adding compiler support for doesn’t seem like a good idea. It also seems you want this for true “base” libs which other libs tend to depend on but not stuff like say Moment.js

dnolen23:06:03

@anmonteiro we didn’t end up making an enhancement ticket for string based require did we?