Proposal: Content Model memory usage optimization on base64 img

[haven2world]

Describe the bug
On mobile devices, available memory is very limited. During the rollout of the Content Model Editor, we noticed that the number of OOM events was increasing, and the system would terminate the web view due to lack of memory.

One of the cases is when the content has a lot of images. Most of the time, we only record the url of the image in CM, but when the url is in base64 format, we may be duplicating data in memory. So I was wondering if we enable dom caching, is it possible to avoid storing base64 strings in the image model by getting the base64 from the src attribute of the cached dom?

[JiuqingSong]

First, javascript should use the same instance for the same string, which means no matter how many places a string is referenced, as long as they are the same, there should be only one instance in memory. You can try take memory dump and see if there is duplicated copy of same string. Second, you can create ObjectUrl for image, we do that in OWA, so image BLOB will only be referenced by a short object url, no matter how large it is.

…

________________________________ From: Haowen Chen ***@***.***> Sent: Tuesday, December 10, 2024 20:36 To: microsoft/roosterjs ***@***.***> Cc: Subscribed ***@***.***> Subject: [microsoft/roosterjs] Proposal: Content Model memory usage optimization on base64 img (Issue #2908) Describe the bug On mobile devices, available memory is very limited. During the rollout of the Content Model Editor, we noticed that the number of OOM events was increasing, and the system would terminate the web view due to lack of memory. One of the cases is when the content has a lot of images. Most of the time, we only record the url of the image in CM, but when the url is in base64 format, we may be duplicating data in memory. So I was wondering if we enable dom caching, is it possible to avoid storing base64 strings in the image model by getting the base64 from the src attribute of the cached dom? — Reply to this email directly, view it on GitHub<#2908> or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFP7D7PWFRFVHZUB7WINYJ32E66M3BFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJLJONZXKZNENZQW2ZNLORUHEZLBMRPXI6LQMWBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTLDTOVRGUZLDORPXI6LQMWSUS43TOVS2M5DPOBUWG44SQKSHI6LQMWVHEZLQN5ZWS5DPOJ42K5TBNR2WLKBZG4YTINJQGEYYFJDUPFYGLJLJONZXKZNFOZQWY5LFVIZDOMZRG44TONBVGCTXI4TJM5TWK4VGMNZGKYLUMU>. You are receiving this email because you are subscribed to this thread. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[haven2world]

Per my test, if the image is loaded in dom, it won't take JS heap's memory. And if I store it in js, then the JS heap will allocate memory for it.

[JiuqingSong]

This should because of the BASE64 string. Suggest use ObjectUrl for image instead.

[JiuqingSong]

This is actually a tracking issue about this to support ObjectUrl in roosterjs. However we don't have bandwidth to do it. But you can still do it from your side.

#942