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
"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.
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.
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?
"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)
The text was updated successfully, but these errors were encountered: