From the to-do list: MPA V1.0: Older issues and tasks
✔ Memory leak
(Completed by Pierre henri Seylan on March 15, 2018)
Comments
Pierre henri Seylan on February 24, 2018:
Right after starting the MPA app, there is a large memory leak. The app is using around 1GB of memory
I could not notice which pattern is causing this leak, and can't remember that it was present in the old version of the app (before the new UI) This could be caused by some UI components, re-painting done in the wrong way, or by something else. Please investigate.
NOTE: This has been tested only on OS X
Karim Alabtakh on March 2, 2018:
the main memory leak is mainly related to large packs images with high resolution. the large images not only case large memory usages but also slow down connection on web site and client app. to fix this problem we should do multiple fixes: 1- reduce the resolution of images before upload them. Or if you want too keep the large images for some other purpose, then it should be done by the server. reducing images to 200px (width) led to a decrease the ram usage to 160mb. (I will send a build to check)
2- also to improve the image file size we may try to use jpeg format, but jpeg lossy compression, so we should check the quality/size of images before use jpeg. NOTE: use jpeg will not affect memory usage because it will be decoded into matrix with same size.
3- try to implement more smarter algorithm to load images into memory. it's most harder part because we should find acceptable solution which will not affect scrolling performance. Soft solution: -load images from the misc only when needed not at startup (based on fact that we will use preloading then this may reduce memory usage) -remove images from memory when pack view is invisible.
More radical solution: -preload images in background when scrolling only for visible items or some custom limit and remove other images from memory. but it may case that if fast scrolling large list which use ram over limited then packs images maybe will not appear directly and take some millisecond to load them from the disk. I have noticed that some browsers use that mechanism for large pages.
But actually I recommend the soft solution because we will use preloading so it will be good enough. also new operating systems good enough in caching unused memory blocks.
Pierre henri Seylan on March 3, 2018:
Thanks for the insights, I think the first step should be the solution listed in point 1: reducing the resolution of the images before uploading them, 200 * 200 px should be enough as the website uses a similar size.
As for the JPEG format, i think we had already discussed that we should also accept this format, but it looks like there is an error with the server. Can you confirm if the error is still present in the new API?
Comments
Pierre henri Seylan on February 24, 2018:
The app is using around 1GB of memory
I could not notice which pattern is causing this leak, and can't remember that it was present in the old version of the app (before the new UI)
This could be caused by some UI components, re-painting done in the wrong way, or by something else.
Please investigate.
NOTE: This has been tested only on OS X
Karim Alabtakh on March 2, 2018:
the large images not only case large memory usages but also slow down connection on web site and client app.
to fix this problem we should do multiple fixes:
1- reduce the resolution of images before upload them.
Or if you want too keep the large images for some other purpose, then it should be done by the server.
reducing images to 200px (width) led to a decrease the ram usage to 160mb. (I will send a build to check)
2- also to improve the image file size we may try to use jpeg format, but jpeg
lossy compression, so we should check the quality/size of images before use jpeg. NOTE: use jpeg will not affect memory usage because it will be decoded into matrix with same size.
3- try to implement more smarter algorithm to load images into memory.
it's most harder part because we should find acceptable solution which will not affect scrolling performance.
Soft solution:
-load images from the misc only when needed not at startup (based on fact that we will use preloading then this may reduce memory usage)
-remove images from memory when pack view is invisible.
More radical solution:
-preload images in background when scrolling only for visible items or some custom limit and remove other images from memory.
but it may case that if fast scrolling large list which use ram over limited then packs images maybe will not appear directly and take some millisecond to load them from the disk.
I have noticed that some browsers use that mechanism for large pages.
But actually I recommend the soft solution because we will use preloading so it will be good enough. also new operating systems good enough in caching unused memory blocks.
Pierre henri Seylan on March 3, 2018:
I think the first step should be the solution listed in point 1: reducing the resolution of the images before uploading them, 200 * 200 px should be enough as the website uses a similar size.
As for the JPEG format, i think we had already discussed that we should also accept this format, but it looks like there is an error with the server.
Can you confirm if the error is still present in the new API?