@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.

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

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

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

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)

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

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

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

probably will need to touch up exclusions in project file

good to know

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

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

^^ yikes

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

The first run has to compile out the transform paths

It is supposed to cache that for future iterations

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

e.g. less of a percepatble hang

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

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

Ah, interesting.

@therabidbanana: Any noticeable difference on your end?

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

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.

this line should be deleted https://github.com/untangled-web/untangled-cookbook/blob/master/recipes/paginate-large-lists/src/server/app/api.clj#L15

defmethod :items is defined twice

@jasonjckn: thanks

@therabidbanana: Hm. bummer.

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.

(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)

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

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

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

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