
Transducers.js Round 2 with Benchmarks - jlongster
http://jlongster.com/Transducers.js-Round-2-with-Benchmarks
======
bhouston
In [https://Clara.io](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.

------
cdsanchez
I'd be really interested in knowing how it compares against lazy.js:
[http://danieltao.com/lazy.js/](http://danieltao.com/lazy.js/)

~~~
ricardobeat
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.

~~~
michaelsbradley
What about transducer support in David Nolen's mori library?

[https://github.com/swannodette/mori](https://github.com/swannodette/mori)

I would be interested to know how its transducer support and performance
compares to transducers.js.

------
est
previous discussion

[https://news.ycombinator.com/item?id=8439547](https://news.ycombinator.com/item?id=8439547)

transducers in Python

[https://news.ycombinator.com/item?id=8444894](https://news.ycombinator.com/item?id=8444894)

------
Touche
What 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?

~~~
Thomasdah
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!

~~~
tel
Monad/Monoid are a different category of things from transducers—think of them
more like an interface than a thing. For instance, a basic model of Transducer
is as follows

    
    
        type Trans a b = forall r . (r -> b -> r) -> (r -> a -> r)
    

and it turns out that this is isomorphic to (e.g. an optimization of) the list
Kleisli arrow

    
    
        type KleiList a b = a -> [b]
    

and lists are monads. For a slightly different reason, this argumentation
leads me to believe that Transducers ought to be monads via the Reader/List
transformer stack. I haven't verified it, however.

Transducers could be monoids, too. You'd need to have two operations like so

    
    
        zero :: Transducer a b
        add  :: Transducer a b -> Transducer a b -> Transducer a b
    

and perhaps there would be necessary restrictions on the choices of `a` and
`b`. It's immediately obvious we could make this work if `a` and `b` were
equal

    
    
        zero :: Transducer a a
        add  :: Transducer a a -> Transducer a a -> Transducer a a
    

as this is now just the "identity" transducer and transducer composition which
satisfy all the laws of monoid.

------
thesorrow
How does this compare to Bacon.js or higland ?

~~~
kbeaty
In regards to Bacon.js, tel had a very interesting response discussing
transducers in relation to FRP/Reactive Programming in another thread [1].

[1]:
[https://news.ycombinator.com/item?id=8447046](https://news.ycombinator.com/item?id=8447046)

------
jamesrom
Time should be on the x-axis. Independent variables on the x-axis and
dependent variables on the y.

EDIT: To clarify, plotting 'seconds' over 'items per second' is needlessly
confusing.

~~~
dancole
>> Independent variables on the x-axis and dependent variables on the y.

Correct. The independent variable being the number of items and the dependent
variable being the time it takes to run said number of items.

>> Time should be on the x-axis.

Time should be on the y-axis. It's the time it takes to execute, given a set
of items.

