RxJs vs Angular Signal performance

Signals don’t win in every aspect after all.

Read the more colorful Medium Member's version here: https://medium.com/@zsolt.deak/rxjs-vs-angular-signal-performance-8b17e2093242

Signals and RxJs are tools for different problems, but they do have some overlaps, they can be used interchangeably in many common situations. We have already measured the memory efficiency of the two in simple situations and even found some ways to leak memory with Signals.

What we measure this time is simple: an event changes a value, and a child component gets that value. The time we record is right before setting the value, until the input changes in the child component. The framework’s overhead can be removed from the equation as it ought to be the same, and also we want to measure an end-to-end scenario, from triggering a change in RxJs/Signal until we can use it. To make it a little bit more complicated both values are derived, using combineLatest and computed .

// RX way 
subj$ = new BehaviorSubject(0);
  constSubj$ = new BehaviorSubject(1);
  cSubj$ = combineLatest([this.subj$, this.constSubj$]).pipe(
    map(([a, b]) => a + b)
  );

  onClickSub(): void {
    this.i++;
    this.timerStart = performance.now();
    this.subj$.next(this.i);
  }

  changedSub(timeEnd) {
    if (this.timerStart) {
      this.subTimeAvg.push(timeEnd - this.timerStart);
    }
    const sum = this.subTimeAvg.reduce((acc, e) => acc + e, 0);
    console.log(sum / this.subTimeAvg.length);
  }

// Signal
  sig = signal(0);
  constSig = signal(1);
  cSig = computed(() => this.sig() + this.constSig());

  onClickSig(): void {
    this.i++;
    this.timerStart = performance.now();
    this.sig.set(this.i);
  }

  changedSig(timeEnd) {
    if (this.timerStart) {
      this.sigTimeAvg.push(timeEnd - this.timerStart);
    }
    const sum = this.sigTimeAvg.reduce((acc, e) => acc + e, 0);
    console.log(sum / this.sigTimeAvg.length);
  }

As for the results, if you look under the hood, both solutions are actually rather simple, there is no meaningful difference between the two, very well within the measurement error.

Hundreds of events’ averages, measurements in ms

Surprisingly, using input signal (and emitting in transform ) made in consistently faster than using set setter function with @Input to emit. But using input signal and an effect listening to that signal for the emit made the whole thing consistently over 1000 events twice as slow.

  in = input.required();

  constructor() {
    effect(() => {
      const i = this.in();
      const sigTimerEnd = performance.now();
      this.out.emit(sigTimerEnd);
    });
  }

  @Output()
  out = new EventEmitter<number>();

still pretty fast

No winners, no losers, but we all suspected these are all well-optimised solutions.

• using RxJs over Signal has no performance implications ✅

• using input Signal over @Input is ever so slightly more efficient ✅

• using effect() strangely takes as long as setting a signal, updating a computation, setting a signal again, and emitting the value ❌