This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (6)
- # beginners (9)
- # boot (33)
- # cider (23)
- # cljs-dev (50)
- # cljsjs (2)
- # cljsrn (9)
- # clojars (1)
- # clojure (216)
- # clojure-czech (1)
- # clojure-dev (5)
- # clojure-italy (23)
- # clojure-russia (18)
- # clojure-spec (11)
- # clojure-uk (53)
- # clojurescript (157)
- # core-async (29)
- # cursive (12)
- # data-science (15)
- # datascript (16)
- # datomic (68)
- # graphql (2)
- # jobs (5)
- # jobs-discuss (1)
- # juxt (17)
- # lein-figwheel (2)
- # luminus (3)
- # off-topic (155)
- # om (3)
- # pedestal (1)
- # portkey (1)
- # re-frame (7)
- # reagent (4)
- # ring (10)
- # ring-swagger (2)
- # rum (11)
- # unrepl (11)
- # yada (2)
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.
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
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.)
@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.
@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
would be nice to have observed perf benefit in the ticket / comments to give a bit more context
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.
I’ll measure that one some more and see if it truly matters beyond an artifact of profiling.
similarly in bootstrapped at least I did see 2 years ago that string concatenation dominates the profile - but to be expected
I think I played around with a couple of things - but I couldn’t find anything that really had any affect
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.
i'm writing guides on how i setup CIDER and how to investigate things so that its hopefully easier to get other contributors
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
@andrewhr you can start up a JVM process (i.e. REPL), attach to it, then start your profile
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.
@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)
@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
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
I thinking more like shim ns which can get require the right thing depending on what’s available
: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
react.dep.node artifact with one namespace with the React stuff you can import , and
react.dep.cljsjs which declares the same namespace
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
@anmonteiro we didn’t end up making an enhancement ticket for string based require did we?