You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Commit message(s) and PR title follows the format [fix|feat|ci|chore|doc]: TICKET-ID: Short description of change made ex. fix: DEV-XXXX: Removed inconsistent code usage causing intermittent errors
Tests for the changes have been added/updated (for bug fixes/features)
Docs have been added/updated (for bug fixes/features)
Best efforts were made to ensure docs/code are concise and coherent (checked for spelling/grammatical errors, commented out code, debug logs etc.)
Self-reviewed and ran all changes on a local instance (for bug fixes/features)
Change has impacts in these area(s)
(check all that apply)
Product design
Backend (Database)
Backend (API)
Frontend
Describe the reason for change
Through other investigations it was surfaced that there was an unnecessary handling of image data in memory, which included caching raw data in a Map. Storing information in a Map is dangerous for unintended memory growth to occur as Map's do not get garbage collected very easily, most times not. Further to this, there is no clear use case to not just using the browser as normal to load image data from the provided urls directly, allowing the browser heuristics to effeciently manage the memory and caching of these image requests.
Does this change affect performance?
Separately fetching data of the image to cache and produce a base64 DataURL is not more efficient than using the browser's baseline primitives directly. This in small sample sizes would be no difference, but larger sample sizes with greater number and filesize of images would lead to improved memory usage and performance within the application.
What feature flags were used to cover this change?
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR fulfills these requirements
[fix|feat|ci|chore|doc]: TICKET-ID: Short description of change madeex.fix: DEV-XXXX: Removed inconsistent code usage causing intermittent errorsChange has impacts in these area(s)
(check all that apply)
Describe the reason for change
Through other investigations it was surfaced that there was an unnecessary handling of image data in memory, which included caching raw data in a Map. Storing information in a Map is dangerous for unintended memory growth to occur as Map's do not get garbage collected very easily, most times not. Further to this, there is no clear use case to not just using the browser as normal to load image data from the provided urls directly, allowing the browser heuristics to effeciently manage the memory and caching of these image requests.
Does this change affect performance?
Separately fetching data of the image to cache and produce a base64 DataURL is not more efficient than using the browser's baseline primitives directly. This in small sample sizes would be no difference, but larger sample sizes with greater number and filesize of images would lead to improved memory usage and performance within the application.
What feature flags were used to cover this change?
fflag_feat_front_optic_1479_improve_image_tag_memory_usage_shortDoes this PR introduce a breaking change?
(check only one)
Which logical domain(s) does this change affect?
ImageEntity (ImageMixin -> Image tag)