# Operator-fusion (Part 1)

DevFeed: [Operator-fusion (Part 1)](<https://devfeed.tech/articles/operator-fusion-part-1-24797.md>)

Original publisher: [Read original article](<https://akarnokd.blogspot.com/2016/03/operator-fusion-part-1.html>)

Author: David Karnok (noreply@blogger.com)

Published: 2016-03-11T13:06:00Z

Content type: article

Language: en

Sources: [Akarnokd - Advanced RxJava](<https://devfeed.tech/sources/akarnokd-advanced-rxjava.md>)

Topics: [reactive](<https://devfeed.tech/topics/reactive.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [implementation](<https://devfeed.tech/tags/implementation.md>), [programming](<https://devfeed.tech/tags/programming.md>), [reactive](<https://devfeed.tech/tags/reactive.md>), [reactive-programming](<https://devfeed.tech/tags/reactive-programming.md>), [reactive-streams](<https://devfeed.tech/tags/reactive-streams.md>), [rxjava](<https://devfeed.tech/tags/rxjava.md>)

## AI overview

This article introduces operator fusion in reactive programming: combining successive operators to reduce dataflow overhead in time and memory. It discusses optimization techniques, experimentation in the reactive-streams-commons repository, and relationships to RxJava, Project Reactor, and Akka Streams.

## Source excerpt

Introduction Operator-fusion, one of the cutting-edge research topics in the reactive programming world, is the aim to have two of more subsequent operators combined in a way that reduces overhead (time, memory) of the dataflow. (Other cutting-edge topics are: 1) reactive IO, 2) more native parallel async sequences and 3) transparent remote queries.) The key insight with operator-fusion is threefold: many sequences are started from constant or quasi-constant sources such as just(), from(T[]), from(Iterable), fromCallable() which don't really need the thread-safety dance in a sequence of operators, some pairs of operators can share internal components such as Queues and some operators can tell if they consumed the value or dropped it, avoiding request(1) call overhead. In this mini-series, I'll describe the hows and whys of operator-fusion, as we currently understand it. By "we", I mean the joint research effort on optimizing Reactive-Streams operators beyond what's there in RxJava 2.x and has been in previous versions of Project Reactor. The experimentation happens in the reactive-streams-commons, Rsc for short, GitHub repository. The results of the Rsc is now driving Project Reactor 2.5 (currently in milestone 2) and verified by a large user base. Hopefully, RxJava can benefit from the results as well (but maybe not before 3.x). If you are following Akka-Streams, you might have read/head about operator-fusion there as well. As far as I could understand their approach, their objective is to make sure more stages of the pipeline run on the same Actor, avoiding the previous, very likely, thread-hopping with their sequences. Essentially, there is now a mode where the developer can define the async boundaries in the pipeline. Does this sound familiar? From day 1, Rx-based libraries let you do this. Generations Reactive libraries and associated concepts evolved over time. What we had 7 years ago in Rx.NET, requirements and implementation-wise is significantly different w