Repository navigation
jpg.decodedBlock should it release memory after usage? #224
Description
Activity
@mhamri it looks like duplicate of #151, but thanks for the detailed description of your use-case!
The memory usage drop from 4GB to 3GB is random, we haven't done actual improvements on this. I think it depends on the input images your service is processing. Do your inputs have a common characteristic? (eg: large photos). If yes, it might be helpful to post a few of them.
Implementing #225 and certain points of #192 should help on this. Unfortunately both are big tasks, so we need your patience here.
well, about the 3gb to 4gb, i'm sure there was some changes, i have a batch of 40 images in one xml file that generates 4gb memory usage. i ran this test file almost 50 times, even before i do update to latest package. after update to the latest package, the usage decreased to 3gb.
i'm not sure it's same with #151, because my question is why the referenced object is not releasing memory if i'm disposing the object correctly? what is keeping a reference to those color and decoder array? I understand the previous memory usage when the decoder and color array was static. but now that is not static why still a reference is kept somewhere to those arrays? you got what do I mean?
It is
ArrayPool. Pools large arrays in a shared (static) pool to reduce gc pressure and prevent LOH issues. We understand this is not the best behavior for many users though, so we want to make this configurable.- I am aware of that, but in memory dump, against previous version the pool didn't mark as static, that's why i thought in new version the behavior of pool has changed. Btw is the pool getting reuse again? I observed in linux debian 0.8 that if i run the same test file multiple times the memory pool grow up to 8gb , look like the pool is keep getting added instead of reusing.…On May 25, 2017 8:42 PM, "Anton Firsov" ***@***.***> wrote: It is ArrayPool. Pools large arrays in a shared (static) pool to reduce gc pressure and prevent LOH issues. We understand this is not the best behavior for many users though, so we want to make this configurable. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#224 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIk0J-Xp6p6U0zVjLmAhDYQ8RDJTcs8Sks5r9XdAgaJpZM4Nl6sw> .
There might be an unexpected behavior (missing dispose calls?) that came with #210. Looks like we need to do a deeper investigation here. @JimBobSquarePants I think we really need to find a way to stress test the library with a larger test image pack.
Agreed, we do.
I hope this help, it's my set of test images, all are stock photos, good quality, and high dpi and pixel
Reacted by James Jackson-SouthThanks! Really appreciate it.
@mhamri If you are still using ImageSharp, check out the beta, the Jpeg decoder uses much less memory now! Let me know if the situation is still critical for you!
Prerequisites
DEBUGandRELEASEmodeDescription
I was using imagesharp 1 alpha 4 48 previousely and my app for a normal task took up to 4gb, today I updated to latest version and saw it decreased to 3gb. thanks for the improvement.
I just ran a profiler and saw that the type of decoded block and color block from static type changed to normal property so I got some concern if i'm doing something wrong. I assume that it should release the resources when I call the dispose method or it reach end of the using statement.
I checked almost all of my code, i have using and dispose for every usage. also the class that wrapp the imagesharp is implementing IDisposable.
Steps to Reproduce
i'm using imagesharp with DI in startup.cs, configServices method:
services.AddTransient<ImageSharpHelper>();and the
imageSharpHelperis like bellow:and i'm calling the class like bellow:
System Configuration