search

JuliaLang / julia

The Julia Programming Language
https://julialang.org/
MIT License
45.57k stars 5.47k forks source link

`deepcopy` works too hard when it should not #31294

Open JeffreySarnoff opened 5 years ago

JeffreySarnoff commented 5 years ago

"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 https://github.com/JuliaLang/julia/issues/31276#issuecomment-470724412

JeffreySarnoff commented 5 years ago

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.

narendrakpatel commented 5 years ago

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?