Holding Subscription object doubles memory usage

[ingun37]

I make a WebGL library that renders some 3D models. I use RxJS to load different parts of the model asynchronuously.

3D models are usually heavy and takes a lot of time so I'm providing abortation feature for users who'd like to stop loading if it takes too long.

I tried holding Subscription objects in my class as member variable so I can unsubscribe on command, then the memory usage got almost doubled.

Benchmarking is done systematically over multiple times so it's accurate that merely holding Subscription objects by changing

class SomeClass {
  foo() {
	loadingTask.subscribe(...)
  }
}

to

class SomeClass {
  subscriptions: Subscription[]
  foo() {
    subscriptions = [
      loadingTask.subscribe(...)
    ]
  }
}

caused the memory issue.

Holding Subscription object as a variable must implicitly retain something other .. what could it be? Has anything similar happened to other RxJS users?

[cartant]

What version of RxJS? I can see an issue that I ought to address in the v7 implementation, but just to be clear, you're talking about holding a subscription to an observable that has either completed, errored or was explicitly unsubscribed, right? Whether or not you hold a subscription to an observable that is currently subscribed will make no difference - except in some degenerate case in which you subscribe to an observable that does nothing and you hold no reference to it.

[ingun37]

The version was 6.6.3

I solved the issue by regulary dereferencing the Subscription objects. I found it was unneccessarily holding it even after unsubscription/completion. However still have no clue why it caused the memory issue. Subscription seems a very simple data structure that shouldn't retain the actual data flows in the observable's pipeline.

[cartant]

The thing is, it's the Subscriber that's returned from subscribe - Subscriber extends Subscription - and the Subscriber holds a reference to the closures passed to subscribe and they hold references to whatever they happen to use.

See the (potential) change to Subscriber that's in #6116.