Closed joschua-fink closed 6 years ago
Modern garbage collectors should work just fine cleaning up for references once the Var / Val is dereferenced or out of scope.
As for obs.detach()
, the Observer
can be attached to several Observable
s, so would you really want that to detach from everything referencing it? Further, it would be problematic as it would create a double-linking, which would create a GC issue as both sides would have to be dereferenced before either could be GD'd.
If you have any other suggestions, contributions, or are interested in providing documentation, I would be very happy to assist in any way I can. Reactify is incredibly powerful, but hasn't received a lot of visibility.
Hey, thank you very much for the clarifications. After taking a closer look your source code I understand now, how you avoid leaks - I initially assumed a slightly different architecture, where Vars and Vals are Observers and Observables at the same time - so exactly the double linking issue you mentioned :-)
I will look definitely further into using reactify. If I have further suggestions or ideas, I'll let you know or send a pull request.
Feel free to create a PR adding some explanation to the README if you think you can add some clarification regarding memory leaks before closing this ticket.
I will do so, if I have an idea how to make it clearer.
Staying with the topic of memory leaks - are you sure that the functions map
and collect
in the Observable
class are not leaking? From my understanding, upon detaching from the Observable
they return, there still remains the Observer
on the original Observable
created in both of the functions (line 106 and 113) in the file Observable.scala
.
I did also some small Benchmarks (nothing which is solid enough to share numbers) comparing reactify to Monix. On the JVM Monix was roughly twice as fast when it came to data propagation. With Scala.js on Chrome the same story. Intrestingly on Firefox reactify was three to four times slower than Monix. Though for most applications this difference in performance should be negligible as both libraries are fast enough for UI programming.
It's not unreasonable to assume Reactify will be somewhat slower. I haven't done a lot of optimizations, but the way Reactify works is a little bit more processing-centric than the other options. If you'd like to create a little benchmark project to show this I'd be happy to see if I can't improve it. I'm actually in the middle of doing exactly that with my logging framework right now.
@joschuafink is there anything left to be done on this issue or can it be closed?
@joschuafink closing the issue due to non-response. If you have any further issues please either create another ticket or comment here and I'll re-open the ticket.
I'm currently evaluating this library for use in a project. So far it looks very promising and I wish I would have found it half a year ago. But I find the documentation not very detailed in some parts.
How do I clean up Vars and Vals that depend on each other? For example:
Is there an easier way to clean up observers: