Fast modification of immutables being part of mutables

[PatrickHaecker]

This might be similar to #18, but more general.

Accessors.jl defines macros which can both be used on objects of mutable and immutable types. In general, structs can include other structs building a tree with the fields being the leaf nodes. Therefore, the tree can contain mutable and immutable types.

All the lenses and all the object creation including the copying seem to be necessary in general for completely immutable trees. Yet, it is not necessary (at least for isbits types) if the path from the leaf node to the root node contains at least one mutable type. In this case pointer arithmetic can be used to modify the field directly (bypassing the constructor).

This can be much more efficient. With the modified version of MemoryMutate.jl, I get a performance ratio of about 3 for the following example:

using MemoryMutate, Accessors, Chairmarks
struct C
    d::Float64
    e::NTuple{16, Int}
end
mutable struct A
    a::Float64
    b::Int
    c::C
end
obj = A(42.0, 42, C(20.0, ntuple(identity, 16)))

julia> @b @mem $obj.c.d = $21.0
5.849 ns

julia> @b @reset $obj.c.d = $21.0
16.638 ns (2 allocs: 176 bytes)

From the user's perspective, however, it might be nice to have a single interface for these modifications. Otherwise, the user would need to check the above mentioned path through the struct tree to decide about which macro to call. And as Accessors.jl is by far the more popular package, I think it makes sense to use its interface.

I don't know how to implement this using a lens, because I am not familiar with these. However, it does not seem to be necessary to use a lens. Would such a functionality fit to the scope of Accessors.jl? Would it need to be implemented using a lens in order to be accepted?

[aplavin]

First of all, thanks for thinking about extending Accessors to support mutations :) In my opinion (wdyt @jw3126?), this functionality is potentially in scope if can be done cleanly.

Although it should be clearly distinguished from immutable objects manipulation that is the core of Accessors. The default @set a.b.c.d = 123 has to return an object completely independent from a, including a copy of mutable structs in it.

I think any functionality like this should be built on optics – it would be a shame not to support all the generality and composability that comes with them :)
See a simple mutating example in the Accessors docs: https://juliaobjects.github.io/Accessors.jl/stable/examples/custom_macros/. Does it look similar to what you have in mind?

---

Also I cannot help but wonder about your specific usecases. Immutable structs are generally more performant in Julia, do you really need the mutability?

[jw3126]

this functionality is potentially in scope if can be done cleanly.

100% agree.

I had trouble installing MemoryMutate on my machine, but I think the more interesting benchmark would use Accessors on an immutable variant of A:

using BenchmarkTools
using Accessors

struct C
    d::Float64
    e::NTuple{16, Int}
end
mutable struct A_liquid
    a::Float64
    b::Int
    c::C
end
struct A_frozen
    a::Float64
    b::Int
    c::C
end
obj_liquid = A_liquid(42.0, 42, C(20.0, ntuple(identity, 16)))
obj_frozen = A_frozen(42.0, 42, C(20.0, ntuple(identity, 16)))

function doit_liquid(obj, d)
    ptr_base = pointer_from_objref(obj)
    ptr_d = Ptr{Float64}(ptr_base + fieldoffset(A_liquid, 3))
    unsafe_store!(ptr_d, d)
    # obj.c = C(d, obj.c.e)
    obj
end
function doit_frozen(obj, d)
    @set obj.c.d = d
end
@btime doit_liquid($obj_liquid, $21.0)      #1.670 ns (0 allocations: 0 bytes)
@btime doit_frozen($obj_liquid, $21.0) #   6.997 ns (1 allocation: 160 bytes)
@btime doit_frozen($obj_frozen, $21.0) #   2.050 ns (0 allocations: 0 bytes)

So is 1.670 ns vs 2.050 ns is still some benefit of using mutation here, but much less than in the original benchmark.