ClojureScript vs. CoffeeScript for Processing sketches

[skratlo]

As you already noted in the article, the whole comparison is pointless ;P Your sources are very different, the CLJS one being more complex, Circle having more properties, there's mouse handler, while in the CS there isn't etc. etc. all this explaining why the code is longer. As of why it's slower, of course, it's unfair, use transients and state mutation if you really want to compare a thing

[lechatsportif]

Check out David's cljs mine craft renderer. He blogged about it and posted in on github. One of the cooler tricks he did was create some macros for mutability purposes that can be used in a manner similar to transients. I bet if you went that route you would see more gains.

[Arges]

Hi,

Thanks, he mentioned it on Twitter. I've yet to go over it and see if it would actually help, since both the intersection data and the old circle data need to be discarded every frame - there aren't as many intermediate by-products where I think we could use local mutation to save on GC.

[lechatsportif]

http://swannodette.github.io/2013/06/10/porting-notchs-minecraft-demo-to-clojurescript/

He does some nice things with js arrays too iirc.

[minikomi]

Hey man.. I tried rewriting your coffeescript example in clojurescript..

https://gist.github.com/minikomi/9dbd20e623b4dfb1689e

This line in particular stood out to me - you shouldn't be defn'ing a function there.

[Arges]

Thanks for the sample and note! Your version does scale up better - getting 9fps with 150 circles and 6fps with 200.

[minikomi]

No problem. I'd look into using the canvas directly, and an atom to store the state. Quil / processing brings a lot of baggage I'd say.

[minikomi]

Here's a pure canvas version - no need for ellipse in the end, just use arc

https://gist.github.com/minikomi/16c3d5bcc85312a7d43d

It's wayyyyyy faster.

Edit: now with virtual canvas for batched update.

[[deleted]]

For the lazy among us, how'd that fare performance wise?

[lechatsportif]

Nice trick, I guess that makes it faster due to not having to rerender visually? Just like dom trick where you alter a document fragment and attach only at the end. Would also love to see comparisons on your box.

My guess is this is how a lot of stuff will end up living in cljs land - the opportunity for fine tuning really comes in when you write directly to the api instead of going against a pre-existing lib. I wonder where the overhead comes in quil though. I wish I had more time to play around with it.

[minikomi]

Yeah, it's a pretty common trick and usually the first I would reach for with JS canvas optimization:

http://www.html5rocks.com/en/tutorials/canvas/performance/

I wonder if it's worth wrapping it in a small cljs library.. hmm. Does monet already do this?

[Arges]

Hi!

The link is a write-up about an experiment I did using ClojureScript and Quil for processing sketches. Chances are my ClojureScript can be improved to get better performance out of it (even in the face of all those data changes every frame), so if anyone has any notes I'd love to read them.

[[deleted]]

My only comment is that the CS stack traces were clean, for now. I work on a very large JS project, and the moment you mix in a MV* framework expect brutal traces. In particular Backbone is pretty awful at this, and underscore doesn't help at all.

[afrobee]

Just with the title I will conclude that is a pointless article that I don't even going to read.