gmac / backbone.epoxy

Declarative data binding and computed models for Backbone
http://epoxyjs.org
MIT License
615 stars 89 forks source link

Performance #71

Closed jhohlfeld closed 10 years ago

jhohlfeld commented 10 years ago

Hi guys,

you should really take a look at the performance of epoxy! I was reading about vue and found a fiddle with some benchmarks. I was curious and included epoxy.. and was shocked!

see for yourself: http://jsfiddle.net/jhohlfeld/cS66g/embedded/result/

maybe i got it wrong, but backbone+epoxy being even SLOWER than pure backbone in this benchmark really is an unsettling thought.

cheers, and thanks for the great work though!

Prinzhorn commented 10 years ago

You're not really using Epoxy.

  1. In backboneInit, don't use a loop for creating the views. Use a Collection with a view property and let Epoxy handle creation and removal of the views. That's where Epoxy really shines (one DOM node per model), it's irrelevant though for this benchmark, which I don't see a point in by the way.
  2. The only thing you use of it is the computed property, which adds slight overhead (@gmac: will the computed be re-evaluated three times when setting all three properties it depends on in one set call?). You're still using an underscore template for rendering, which you don't need at all.

http://jsfiddle.net/cS66g/1/

This didn't improve performance, but the benchmark itself even says "you wouldn't be doing this in an actual app.". Don't get fooled by such benchmarks. Just look at the epoxy code, its clean and in an actual app it works very well.

gmac commented 10 years ago

Thank you, @Prinzhorn for fielding this. I couldn't offer a better response. First, Backbone isn't "slow". It may not render 100 animating circles efficiently, but then that's not what the tool was designed to do. Likewise, Epoxy isn't necessarily "slow", although it certainly won't speed up the base Backbone lib (adding more code into a project rarely increases raw performance). Epoxy is simply designed to extend Backbone with another workflow, and provides the code required for that workflow.

Ultimately, these sorts of performance benchmarks are virtually worthless because they compare the efficiency of tools doing jobs they're poorly suited for. While both a hammer and a jackhammer could technically be used to pound in a nail, you don't NEED more than a hammer for the job, so the bigger tool performs badly by comparison. Likewise, both tools could technically break through concrete, although a crummy little hammer is going to be underwhelming for performing that job.

jhohlfeld commented 10 years ago

Thanks for the clarification. I'm happy you gave me that insight. I enjoy using your lib very much indeed!