outr / reactify

The first and only true Functional Reactive Programming framework for Scala.
MIT License
86 stars 4 forks source link

how to clean up properly? #21

Closed joschua-fink closed 6 years ago

joschua-fink commented 6 years ago

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:

val myVar = Var(1)

class Test {
  val myVal = Val(myVar * 2)
}

var test = new Test
println(test.myVal())

// dereferencing Test to allow it to be garbage collected
test = null
// is myVal now also garbage collected or does this create a memory leak?

Is there an easier way to clean up observers:

val myVar = Var(1)
val obs = myVar.attachAndFire(println)
myVar.detach(obs) // why not obs.detach()?
darkfrog26 commented 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 Observables, 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.

joschua-fink commented 6 years ago

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.

darkfrog26 commented 6 years ago

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.

joschua-fink commented 6 years ago

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.

darkfrog26 commented 6 years ago

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.

darkfrog26 commented 6 years ago

@joschuafink is there anything left to be done on this issue or can it be closed?

darkfrog26 commented 6 years ago

@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.