Possible performance improvements for `deepcopy`?

Internals & Design
,
1

I created this small package here GitHub - Tortar/FastDeepCopy.jl which outperform the current deepcopy implementation by quite a bit, for a vector of mutable structs it is more than 200 times faster as you can see in the ReadMe of the repository. The implementation is quite small and simple: FastDeepCopy.jl/src/FastDeepCopy.jl at main · Tortar/FastDeepCopy.jl · GitHub. I’d like to ask to someone more knowledgeable on internals if my code relies on some assumptions which can’t be met in general (I didn’t find any by myself) and so it is not good for the standard library, or if instead a similar implementation could be added to it?

2 Likes
2

Could include versioninfo() in the README to better describe the benchmark conditions, particularly important because deepcopy.jl has changed in the last few minor revisions.

1 Like
4

I think there could be semantic differences around stuff like preserving identities. For example this works in Base:

julia> a = [1];

julia> b = [a, a]
2-element Vector{Vector{Int64}}:
[1]
[1]

julia> b[1] === b[2]
true

julia> c = deepcopy(b)
2-element Vector{Vector{Int64}}:
[1]
[1]

julia> c[1] === c[2]
true

From a quick look I don’t think your version keeps this property but I haven’t tried.

7 Likes
5

I’m guessing that’s what the stackdict is for?

6

I’m guessing that’s what the stackdict is for?

yes, that’s what it seems to be achieving.

If you are interested, I found something to improve anyway hopefully :D: Don't use `deepcopy_internal(xi, stackdict)` for bits fields by Tortar · Pull Request #52597 · JuliaLang/julia · GitHub

2 Likes