Memory Leak when first using picker #73
Comments
|
@Cez95 Thanks for the report, I'm taking a look at the moment and let you know if I have any updates :) |
|
Silly question in the meantime, picker.didSelectImage = { [unowned picker] img in
// image picked
// code...
picker.dismiss(animated: true, completion: nil)
} |
|
unowned
…On Mon, Apr 2, 2018 at 1:30 PM, S4cha ***@***.***> wrote:
Silly question in the meantime,
Are you using [weak picker] or [unowed picker] when using the api?
picker.didSelectImage = { [unowned picker] img in
// image picked // code... picker.dismiss(animated: true, completion: nil)
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#73 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AbDeLax-ZUYBkdjz87GWD79jZCvrzc0Gks5tkmAZgaJpZM4TBiOz>
.
|
|
I have tried it with both weak and unowned and still get a memory leak btw
On Mon, Apr 2, 2018 at 3:20 PM, Christopher Olson <ceolson95@gmail.com>
wrote:
… unowned
On Mon, Apr 2, 2018 at 1:30 PM, S4cha ***@***.***> wrote:
> Silly question in the meantime,
> Are you using [weak picker] or [unowed picker] when using the api?
>
> picker.didSelectImage = { [unowned picker] img in
> // image picked // code... picker.dismiss(animated: true, completion: nil)
> }
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#73 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AbDeLax-ZUYBkdjz87GWD79jZCvrzc0Gks5tkmAZgaJpZM4TBiOz>
> .
>
|
|
Hi guys, Great lib - continue the good work because it's shaping to become one of the best imagePicker out there (and I've checked quite a few out)! I wanted to also chime here as I am having a huge memory spike (60-70MB) as well but for me it happens when I apply any filter. It's not surprising as I can see the lib is loading a bunch of GC related frameworks (Metal, etc.) but they don't appear to ever get released from memory, even once the app enters background. Would be great to be able to optimize the memory usage once the picker is dismissed so that the app doesn't get killed by the OS when in the background... Thanks again for the hard work, |
|
Hello guys! For sure, the picker has memory leaks. I tested it with Xcode instruments, but not enough professional in them. If you could help us with eliminating these leaks, respect for you)) |
|
@fschaus First of all thanks a ton for the kind words 😊. We're trying our best to become to go-to solution for image picking 🚀 . Cheers, |
|
Thanks for the quick response guys! @NikKovIos I am also pretty bad at instruments (+ it keeps crashing on my app) so I can only use the visual memory debugger... I took a quick look at the code for the filter and there is no super obvious retain cycles there as far as I can tell. Happy to continue digging a bit and reporting what objects I see retained in memory; that might then help you both get the intuition of what could be driving this. Let me know if that would be helpful, |
|
Hey guys, I updated to 3.1.1 and the memory mgmt is much improved - nicely done! A good and a bad news though - the bad is that the memory leak is still present when applying filter, the good is that I was able to identify the cases in which it happens vs. not by looking closely at the console. Whenever I select any picture in my picture library, I get one of the two below messages:
Tbh I don't know what class/ method prints these messages but I noticed that in the first case (.JPG) the memory works just fine once I load the filters - it peaks but gets released once the filter screen is dismissed. It's in the 2nd case when using the High Efficiency File Format (or at least when that error message appears) that the memory retention happens - peaking by 100-150MB and only getting ~30-50MB back. Not sure if the imagepicker handles the two files differently (I guess it does given the vastly different memory outcomes) but that seems to be the culprit. Hope this helps (a little bit at least)! |
|
Hey Francois, Thank you for taking the time to add details to this issue, this is very appreciated :) I've tried to look for the possible leak this afternoon but can't. Actually the memory looks pretty sane on my end.
The spikes are each time I was applying filters but they come back to normal whenever I change view or close the picker. Which indicates that the memory is freed. Cheers, |
|
Cool! If anything it might be corner case when using that specific type of picture (HEIC) that the leak appears. I would be happy to dig into this next week and report back if I can find anything specific... To help me in that could you share with me:
Any hints you can give me on where to focus first would be highly appreciated! Thanks, |
|
Hey guys, I owe you an update on this. It seems that this is now resolved. I did extensive profiling with my release build and don't see any memory traces/ leaks, except for an array of filters (but which is less than 8-16 bits) so all good! Feel free to close this! Thanks again for all the hard work! |
|
@fschaus, Indeed the print message was generated and not from our code. Maybe the remaining memory issue was solved along with the log issue #81. Thank very much for taking the time to post an update, this is very appreciated :) Closing this for now, @Cez95 feel free to reopen if needed. |
I have tested this multiple times and every device possible. Whenever I open my app fresh and grant the device permission to access my photos etc, the first time YP opens it creates a memory leak. Specifically on line 44 - 48,
private let loadingContainerView: UIView = { let view = UIView() view.backgroundColor = UIColor(white: 0, alpha: 0.8) return view }()I have tried pushing it to the main thread to no avail. Great pod btw.
The text was updated successfully, but these errors were encountered: