7 ms·

Transducers.js Round 2 with Benchmarks

104 points by jlongster 12y ago

cdsanchez 12y ago
I'd be really interested in knowing how it compares against lazy.js: http://danieltao.com/lazy.js/ http://danieltao.com/lazy.js/
- ricardobeat 12y ago
  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 12y ago
    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.
jamesrom 12y ago
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.
- nmjohn 12y ago
  > Time should be on the x-axis. Independent variables on the x-axis and dependent variables on the y. The graph is correct - the independent variables in this case are the number of items in the array (the x axis) and the library being tested (each line). The dependent variable in this case is time - which is why it is on the y axis.
  - deleted 12y ago
    [deleted]
- dancole 12y ago
  >> 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.
  - deleted 12y ago
    [deleted]
    - XaspR8d 12y ago
      It's simply plotting 'seconds' over 'items'. Neither axis is a compound unit.
- mattdeboard 12y ago
  I think you're just confused. From the post: > The graph below shows the time it took to run versus the size of [the array]
bhouston 12y ago
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.
est 12y ago
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 12y ago
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?
- juliangamble 12y ago
  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-transducers/ 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).
- coldtea 12y ago
  Because lots of day-to-day uses large datasets? Especially since 10,000 item array is considered "large" from that perspective.
- Thomasdah 12y ago
  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 12y ago
    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 12y ago
How does this compare to Bacon.js or higland ?
- kbeaty 12y ago
  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
deleted 12y ago
[deleted]

104 points by jlongster 12y ago

I'd be really interested in knowing how it compares against lazy.js: http://danieltao.com/lazy.js/ http://danieltao.com/lazy.js/

ricardobeat 12y ago
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 12y ago
  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.

jamesrom 12y ago

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.

nmjohn 12y ago
> Time should be on the x-axis. Independent variables on the x-axis and dependent variables on the y. The graph is correct - the independent variables in this case are the number of items in the array (the x axis) and the library being tested (each line). The dependent variable in this case is time - which is why it is on the y axis.
- deleted 12y ago
  [deleted]
dancole 12y ago
>> 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.
- deleted 12y ago
  [deleted]
  - XaspR8d 12y ago
    It's simply plotting 'seconds' over 'items'. Neither axis is a compound unit.
mattdeboard 12y ago
I think you're just confused. From the post: > The graph below shows the time it took to run versus the size of [the array]

bhouston 12y ago

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.

est 12y ago

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 12y ago

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?

juliangamble 12y ago
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-transducers/ 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).
coldtea 12y ago
Because lots of day-to-day uses large datasets? Especially since 10,000 item array is considered "large" from that perspective.
Thomasdah 12y ago
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 12y ago
  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 12y ago

How does this compare to Bacon.js or higland ?

kbeaty 12y ago
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

deleted 12y ago

[deleted]