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

deepcopy works too hard when it should not #31294

Open
JeffreySarnoff opened this issue Mar 8, 2019 · 2 comments
Open

deepcopy works too hard when it should not #31294

JeffreySarnoff opened this issue Mar 8, 2019 · 2 comments
Labels
performance Must go faster

Comments

@JeffreySarnoff
Copy link
Contributor

"Memoization" is a bit of a misnomer here --- the purpose of the dictionary is not to avoid redundant computation, it's to ensure the new object has the exact same reference structure as the original. So it's expected to be more expensive. However, of course this is not necessary just to deepcopy one BigFloat. So that's an optimization we could try to do in deepcopy.

Originally posted by @JeffBezanson in #31276 (comment)

@JeffreySarnoff
Copy link
Contributor Author

It seems that types that are library based, where the library handles all the grudgework of copying one value to a new instance of the type never need the type-associated deepcopy referece dict. We know that processing through that dict has a substantive cost in the case of BigFloats (see some of the discussion in this issue). Julia would benefit by having a multifaceted handling of the transition from deepcopy to relevant internal_deepcopy realizations.

@JeffBezanson JeffBezanson added the performance Must go faster label Mar 8, 2019
@narendrakpatel
Copy link
Contributor

I am interested in solving this issue. IIRC there was a suggestion to do lazy evaluation of arguments or something similar. The main idea was to only initialize the IdDict when "needed". But I don't know how one can implement such a thing.
@JeffBezanson can you give me some leads on how to approach this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Must go faster
Projects
None yet
Development

No branches or pull requests

3 participants