Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add static constructors for TrackedArray and TrackedObject that don't copy #73

Open
boris-petrov opened this issue Apr 26, 2021 · 2 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@boris-petrov
Copy link

I know that in the README it's explicitly written that they copy their arguments for safety (which is great and makes sense) but sometimes one might want to save on memory and performance when they know that the original won't be accessed any more from anywhere else. I'm fine with calling the methods UNSAFE_CREATE or something but just the ability to do that would be nice.

I actually have copy-pasted locally the implementations from this library and added that single static method.

I could open a PR if that's acceptable.

@chriskrycho
Copy link
Collaborator

This is an interesting idea. I can see the argument for creation time for sure since that ends up being O(N) on the size of the consumed iterable. In terms of memory usage, the issue seems less dire: if you stop using the original anywhere else, it will be garbage collected. The only time I can see that being an issue is if you're dealing with an extremely large array such that having two copies in memory for any amount of time causes problems. 🤔

@chriskrycho chriskrycho added enhancement New feature or request question Further information is requested labels May 27, 2021
@runspired
Copy link

When I copied TrackedArray to begin the spike for EmberData I also removed the copy. It is never the case for us that the original array can be mutated, and it may be hundreds of thousands of records large (I'd say millions but the only app I've seen with a million records of one type needed serious help due to the memory pressure).

You can find that implementation here: https://github.com/emberjs/data/pull/8134/files#diff-e677c61aa8be87c5dc671c05409d1bcb26134ebef595bd6fc5ed0df0d4049889

It also contains a number of other changes as we (1) needed actual proxying behavior not just tracking and (2) it never makes sense to have a tag per-index so we removed that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants