In https://Clara.io we identified that _.each() and other types of function-based helpers were incredibly slow (even lodash was slow) and we had to replace these constructs in performance critical areas with raw for-loops. Three.JS we also did this.
Transducers.js Round 2 with Benchmarks
11–20 of 22 posts
Re: Transducers.js Round 2 with Benchmarks
#12previous discussion
https://news.ycombinator.com/item?id=8439547
transducers in Python
Re: Transducers.js Round 2 with Benchmarks
#13What problem does this solve? It seems to trade more-verbose code for being more performant in large datasets. That seems reasonable. But otherwise, in day-to-day code why would I use this?
Re: Transducers.js Round 2 with Benchmarks
#14What problem does this solve? It seems to trade more-verbose code for being more performant in large datasets. That seems reasonable. But otherwise, in day-to-day code why would I use this?
This is an example usage based on Dr Seuss: "Green Eggs and Transducers" via @gigasquid
http://gigasquidsoftware.com/blog/2014/09/06/green-eggs-and-...
(note this is in Clojure not JavaScript - but the ideas and usages are the same).
Re: Transducers.js Round 2 with Benchmarks
#15What problem does this solve? It seems to trade more-verbose code for being more performant in large datasets. That seems reasonable. But otherwise, in day-to-day code why would I use this?
Because lots of day-to-day uses large datasets? Especially since 10,000 item array is considered "large" from that perspective.
Re: Transducers.js Round 2 with Benchmarks
#16I'd be really interested in knowing how it compares against lazy.js: http://danieltao.com/lazy.js/
My thoughts. edit: added lazy.js to the benchmark and transducers.js wins hands down. Lazy also starts way behind _/lodash and only catches up after >50k elements.
What about transducer support in David Nolen's mori library?
https://github.com/swannodette/mori
I would be interested to know how its transducer support and performance compares to transducers.js.
Re: Transducers.js Round 2 with Benchmarks
#17How does this compare to Bacon.js or higland ?
Re: Transducers.js Round 2 with Benchmarks
#18[deleted]
Re: Transducers.js Round 2 with Benchmarks
#19How does this compare to Bacon.js or higland ?
In regards to Bacon.js, tel had a very interesting response discussing transducers in relation to FRP/Reactive Programming in another thread [1].
Re: Transducers.js Round 2 with Benchmarks
#20What problem does this solve? It seems to trade more-verbose code for being more performant in large datasets. That seems reasonable. But otherwise, in day-to-day code why would I use this?
The goal is to be less-verbose.
You are able to use tansducer-based functions (map, filter, ...) on any datastructure that is iterable. For me, performance is a bonus.
I do not know how this compares to a monad/monoid. If anyone can explain, please go ahead. Thx!