Fork me on GitHub
#untangled
<
2016-05-31
>
tony.kay17:05:02

@currentoor: @ethangracer I just tried optimizing some of the post-merge functions using specter. I pushed a new JAR of 0.4.11-SNAPSHOT to clojars. I'd be interested if it helps either of your apps on rendering speed.

tony.kay17:05:17

NOTE: I had to touch server as well...it was using an older version of specter, and the API changed slightly...0.5.1-SNAPSHOT of server is up on clojars now as well

therabidbanana17:05:53

Heh - was just about to complain about that @tony.kay 🙂

tony.kay17:05:11

yeah, I was doing some full-stack verification...obviously broke 😉

therabidbanana17:05:43

Pulling it up on our side to take a look now - since I was already working on a branch to reduce the size of reports for performance (indirectly limiting amount of time needed to merge)

ethangracer18:05:06

Anyone else getting this on compilation?

WARNING: Use of undeclared Var cljs.js/*eval-fn* at line 52 resources/public/js/compiled/specs/com/rpl/specter/impl.cljs
WARNING: cljs.js/*eval-fn* not declared ^:dynamic at line 52 resources/public/js/compiled/specs/com/rpl/specter/impl.cljs
WARNING: Use of undeclared Var cljs.js/*eval-fn* at line 52 resources/public/js/compiled/specs/com/rpl/specter/impl.cljs
WARNING: Use of undeclared Var cljs.js/*eval-fn* at line 52 resources/public/js/compiled/specs/com/rpl/specter/impl.cljs
WARNING: Use of undeclared Var cljs.js/js-eval at line 52 resources/public/js/compiled/specs/com/rpl/specter/impl.cljs
WARNING: Use of undeclared Var cljs.js/*eval-fn* at line 52 resources/public/js/compiled/specs/com/rpl/specter/impl.cljs
WARNING: Use of undeclared Var cljs.js/eval at line 53 resources/public/js/compiled/specs/com/rpl/specter/impl.cljs
WARNING: Use of undeclared Var cljs.js/empty-state at line 53 resources/public/js/compiled/specs/com/rpl/specter/impl.cljs

tony.kay18:05:21

yeah...I was seeing that, but didn't cause runtime problem

tony.kay18:05:32

I think it is because specter cljs is built against a diff version of cljs

tony.kay18:05:42

probably will need to touch up exclusions in project file

ethangracer18:05:41

hard to tell if the rendering is appreciably faster but it does appear to be somewhat better for large amounts of data

tony.kay18:05:46

actually, a quite old version of cljs....just looked: 1.6 clojure and 0.0-3211 cljs 😞

tony.kay18:05:01

I'm still not using the query optimization idea...but I thought this might be a decent first brush...NOTE: It may get faster over time

tony.kay18:05:09

The first run has to compile out the transform paths

tony.kay18:05:23

It is supposed to cache that for future iterations

tony.kay18:05:58

rendering itself is not what this changes...it should make the time between a server response and a re-render shorter

tony.kay18:05:52

e.g. less of a percepatble hang

jasonjckn18:05:59

I talked to nathan at the conference, i think spectre is well maintained he said he hadn't had time to learn CLJS yet and david nolen did a lot of the CLJS work on spectre

jasonjckn18:05:51

besides that though he uses it daily for his own CLJ projects / company

tony.kay18:05:48

Ah, interesting.

tony.kay18:05:23

@therabidbanana: Any noticeable difference on your end?

therabidbanana19:05:31

Hard to say, but so far doesn't seem like it. Chrome is having issues showing me the timelines I'm tracing.

therabidbanana19:05:29

I think our dataset with deeply nested hashes causes some pathological performance issues. Finally got a trace and it looks like it might be a bit faster, but still perceptible hang.

jasonjckn19:05:46

defmethod :items is defined twice

therabidbanana20:05:41

Kind of makes sense - as I understand it the way specter can get performance gains is by having a somewhat known structure to precompile paths for - if you end up having to walk the tree, it's still going to end up having slower performance.

therabidbanana20:05:14

(That's my mostly-uninformed guess/opinion based on what I read in the readme and played with in the repl using specter. I could be off-base on that point)

adambrosio21:05:40

sounds right, i think specter/walker is internally just a clojure.walk/postwalk

tony.kay21:05:23

could be...I'm new to it as well.

tony.kay21:05:07

if it isn't a net gain, we might want to revert it so we can remove the dependency

jasonjckn22:05:07

i thought during his talk nathan showed benchmarks that showed it was faster than get-in and update-in when using compiled paths, if so, it must be lower cost than walk/postwalk