Reactive Ruby

Malte Viering cu26mawy at rbg.informatik.tu-darmstadt.de
Wed Jul 22 12:48:08 UTC 2015


Hallo Stefan,

an important disclaimer is that the scope of our evaluation is still 
rather limited which is also why we did not include any performance 
numbers to the announcement of Reactive Ruby. However, we are happy to 
share our current results.

The evaluation is based on benchmarks which measure the time to 
propagate changes through a dependency graph. The result is compared to 
an Observer design pattern implementation that mimics the same 
functionality.

We consider graphs shaped like a chain, fan and reverse fan. I attached 
pics that visualize the graph structure of these benchmarks. In all 
benchmarks the nodes perform simple calculations, like adding a constant 
value to the value of their predecessor node or adding the values of all 
predecessors together. In the chain and fan benchmarks 200k change 
events are propagated and in the reverse fan benchmarks 1.6kk change 
events are propagated.

The measured time in these benchmarks is the following:

  

  

	

Reactive Ruby

	

Observer

Chain

	

0.02 sec

	

0.02 sec

Fan A

	

0.1  sec

	

0.08 sec

Fan B

	

0.08 sec

	

0.03 sec

Reverse fan A

	

0.1  sec

	

0.13 sec

Reverse fan B

	

0.02 sec

	

0.03 sec

  

We think that these initial results are promising as they show that -- 
at least in these benchmarks -- Reactive Ruby can reach around the same 
performance than the hand-made observer pattern. We also evaluated the 
performance of Reactive Programming languages in JavaScript with a 
similar benchmark setup. In that evaluation Rx.JS was on average around 
a factor 10 slower than the handmade Observer pattern, Rx.JS was the 
fasted evaluated RP languages in JS.

Best

Malte Viering


Am 21.07.2015 um 12:17 schrieb Stefan Marr:
> Hi Malte:
>
>> On 20 Jul 2015, at 22:40, Malte Viering <cu26mawy at rbg.informatik.tu-darmstadt.de> wrote:
>>
>> Despite its increasing popularity Reactive Programming still suffers
>> from a significant performance overhead. In my thesis, I looked into
>> the option of using Truffle to provide an efficient runtime system for
>> Reactive Programming.
> Very interesting project, thanks for sharing!
>
> Do you perhaps have some numbers to share with respect to performance?
>
> Thanks
> Stefan
>



More information about the graal-dev mailing list