Memory leak when loading timelines.

[ht990332]

Reproduction steps:

1. open a channel A where someone just posted an image. Note memory using system monitor or top or whatever tool.
2. Switch to another channel B.
3. Switch back to channel A. Note the memory increase.
4. Switch to channel B. Note that memory did not increase because no one posted an image here.
5. Switch back to channel A. Memory increases again on the same image.

It looks like the same image gets loaded into memory several times.

[viktorstrate]

@beezly could this have something to do with the recent media cache implementation?

[beezly]

I'll take a look. I'm pretty sure there is a limit on the cache so it should never consume RAM uncontrollably, but it would impact the cache hit rate if it was duplicating entries.

[ht990332]

if the media URIs are unique, you can hash them and use a hash -> object dictionary.
then on each navigation between channels, hash the link again and check if it is in the dictionary.

[viktorstrate]

@ht990332 this is how it currently works (or at least is supposed to work)

[beezly]

There was a missing return which meant it was finding the cached content, but then acting as if there was a cache miss and proceeding to redownload the content and cache it again. #93 fixes it. I've also created another issue #94 to implement a limit on NSCache size and an associated PR.

[viktorstrate]

I can reproduce a memory leak, just by switching between two rooms. Here I selected a room and repeatedly pressed the up and down arrow keys to continously load the timeline for two rooms. This was tested on the #93 PR, and further more the timelines didn't have any visible images, so I think the memory leak is unrelated to images (or at least there's more leaks).

I've updated the title of the issue to not just be about images.

[beezly]

It looks like something is retaining all of the references to timeline when we switch between channels. If I open a single channel and then switch 20 times between two channels, I see ~20x growth in objects on the heap.

[viktorstrate]

Yes, I have previously caught some memory leaks where some tasks would capture self strongly. Writing Task { [weak self] in ... }, fixed those cases.

The best way to hunt them down I've found so far is to add a print in the deinit of the suspected objects, and then verifying that they are called. Maybe Instrument's leak detection can also be useful, but I haven't had much luck with that yet (maybe I just don't understand how to use it properly though).

We need to investigate this more :)

EDIT: Oh, it looks like you've already opened a PR. I'll have a close look later, thanks!