CODEWITHSUNDEEP
javareactive-programmingproject-reactor
Kristof
Kristof

Reputation: 1704

Does it make sense to use Reactive Programming from a performance standpoint when not dealing with slow IO?

Using Reactive Programming with, for example, Java and Project Reactor makes a lot of sense when dealing with slow IO, or when you want to stream back results to the end-user. The code you write tends to look cleaner - similar to when using Functional Programming and Streams - but you're also forced to write things differently, which makes life harder for programmers new to the concept.

I was wondering whether it makes sense to use from a performance standpoint in general? In case of a program without any I/O apart from some screen output (like calculating infinite PI numbers, or Fibonacci sequences), won't it just slow down your calculations? Or do the gains in your code cleanliness make that a small price?

Upvotes: 5

Views: 3582

Answers (3)

user1803551
user1803551

Reputation: 13407

In general, different paradigms are suitable for different problems and the probable truth is that a problem is solved by a combination of those paradigms. Here is a lightweight talk by Brian Goetz about it. You can't generalize "use RP when dealing with slow I/O and FP when calculating PI" or something like that.

You're touching several completely orthogonal subjects here.

The code you write tends to look cleaner

Completely depending on the syntax of the language and the facilities it provides. Java has the JavaFX binding API which can make RP very clean in Java, but without it it can look very messy. As an example, in language A a result is not bound to its arguments and if you do want it to behave reactively, you have to state it:

a = b + c;
b = b + 1; // a doesn't change
a = react(b + c);
b = b + 1; // a increases by 1

So RP is more messy in this language. In language B it's the opposite - the result is bound by default and if you don't want that you have to specify it, so implementing RP is less messy, but implementing something else is more messy.

but you're also forced to write things differently, which makes life harder for programmers new to the concept.

As is for any paradigm. Wasn't it the same case when OO sprung to life? Think about someone who did FP all the time and now they need to read OO code. Their life is harder just the same.

I was wondering whether it makes sense to use from a performance standpoint in general?

Why not? With lazy computation you have virtually no performance issue. In the above code example, a doesn't need to be updated every time b or c are changed if the value of a isn't used. Think of the pseudo-code react as specifying a formula - "do this when you need the value of a" - and not as a constant relation - "a must always be this".

This is also what JavaFX bindings do. It would be terribly expensive to continuously update all bound values. Whenever a read operation occurs, then and only then update the value and return it.

The question is: should the value react to changes and not whether doing so will be easier to read or have better performance.

Upvotes: 0

Grzegorz Piwowarek
Grzegorz Piwowarek

Reputation: 13773

It depends on the problem you are trying to solve - but if you look at that only from a strict performance standpoint? Probably not, but...

  • Every new concept/paradigm is perceived as hard at the beginning.
    It's always hard to change one's way of thinking to absorb the
    conceptual change.
  • Reactive is not supposed to address performance(unless you do a lot of blocking) but improve overall responsiveness/scalability/resiliency of your system thanks to the asynchronous message-driven architecture.
  • By utilizing declarative approach, you achieve real Inversion of Control(yeah, that's not only Dependency Injection) code written using the reactive approach looks different but is much simpler because you abstract out handling asynchronous computations, thread management, scheduling, the composition of parallel data streams, back pressure, etc., and do not need to deal with that by yourself(imagine refactoring that later on)

So, the classical asynchronous approach is a solution for dealing with slow IO. The reactive approach is much more than that.

Upvotes: 6

Javier Toja
Javier Toja

Reputation: 1762

As far as i understand reactive programming is not only about performance is also about scalability, you want to use reactive programming when you know that your application is going to have an increasing demand on the future and you plan your architecture in order to handle that. Apart from reactive programming there are other few techniques like micro-services or SOA to deal with this problems.

In my opinión using this strategies depends completely on the problem, because nothing is free and usually development times are greater when you develop this kinds of architectures depending on (you/your team) experience.

To send data to your client you can use other techniques like polling or pushing data with web-sockets or queues/topics where you post updated data.

Upvotes: 0

Related Questions