Bad idea, would avoid using this pkg about accessors.jl

[aplavin]

It's built on ConstructionBase.setproperties that provides an efficient way to set multiple properties. Feel free to use that function!

[ronisbr]

We use Accessors.jl a lot in SatelliteToolbox.jl ecosystem, which helped to increase the performance by a huge margin. It is just awesome.

In the past, I tested exactly this behavior. I am not very knowledgeable in compilers, but it seems that most of time the compiler can avoid creating those multiple objects inside the code. For example:

using Accessors

struct MyStruct
    a::Int64
    b::Int64
    c::Int64
    d::Int64
end

function modstruct1(s::MyStruct)
    @reset s.a = 10
    @reset s.d = 10
    return s
end

function modstruct2(s::MyStruct)
    s = Accessors.ConstructionBase.setproperties(s, (a = 10, d = 10))
    return s
end

julia> modstruct1(MyStruct(1, 2, 3, 4))
MyStruct(10, 2, 3, 10)

julia> modstruct2(MyStruct(1, 2, 3, 4))
MyStruct(10, 2, 3, 10)

julia> @code_llvm modstruct1(MyStruct(1, 2, 3, 4))
;  @ REPL[3]:1 within `modstruct1`
define void @julia_modstruct1_194([4 x i64]* noalias nocapture noundef nonnull sret([4 x i64]) align 8 dereferenceable(32) %0, [4 x i64]* nocapture noundef nonnull readonly align 8 dereferenceable(32) %1) #0 {
top:
;  @ REPL[3]:2 within `modstruct1`
; ┌ @ /Users/ronan.arraes/.julia/packages/Accessors/hjkBO/src/optics.jl:375 within `set`
; │┌ @ /Users/ronan.arraes/.julia/packages/ConstructionBase/JFKjZ/src/ConstructionBase.jl:131 within `setproperties`
; ││┌ @ /Users/ronan.arraes/.julia/packages/ConstructionBase/JFKjZ/src/ConstructionBase.jl:213 within `setproperties_object`
; │││┌ @ /Users/ronan.arraes/.julia/packages/ConstructionBase/JFKjZ/src/ConstructionBase.jl:103 within `getproperties`
; ││││┌ @ broadcast.jl:903 within `materialize`
; │││││┌ @ broadcast.jl:1118 within `copy`
; ││││││┌ @ ntuple.jl:69 within `ntuple`
; │││││││┌ @ ntuple.jl:72 within `macro expansion`
; ││││││││┌ @ broadcast.jl:1118 within `#31`
; │││││││││┌ @ broadcast.jl:682 within `_broadcast_getindex`
; ││││││││││┌ @ broadcast.jl:709 within `_broadcast_getindex_evalf`
; │││││││││││┌ @ Base.jl:37 within `getproperty`
              %memcpy_refined_src = getelementptr inbounds [4 x i64], [4 x i64]* %1, i64 0, i64 1
; └└└└└└└└└└└└
;  @ REPL[3]:4 within `modstruct1`
  %newstruct.sroa.0.0..sroa_idx = getelementptr inbounds [4 x i64], [4 x i64]* %0, i64 0, i64 0
  store i64 10, i64* %newstruct.sroa.0.0..sroa_idx, align 8
  %newstruct.sroa.2.0..sroa_idx5 = getelementptr inbounds [4 x i64], [4 x i64]* %0, i64 0, i64 1
;  @ REPL[3]:3 within `modstruct1`
; ┌ @ /Users/ronan.arraes/.julia/packages/Accessors/hjkBO/src/optics.jl:375 within `set`
; │┌ @ /Users/ronan.arraes/.julia/packages/ConstructionBase/JFKjZ/src/ConstructionBase.jl:131 within `setproperties`
; ││┌ @ /Users/ronan.arraes/.julia/packages/ConstructionBase/JFKjZ/src/ConstructionBase.jl:217 within `setproperties_object`
; │││┌ @ REPL[2]:2 within `MyStruct`
      %2 = bitcast i64* %memcpy_refined_src to <2 x i64>*
      %3 = load <2 x i64>, <2 x i64>* %2, align 8
; └└└└
;  @ REPL[3]:4 within `modstruct1`
  %4 = bitcast i64* %newstruct.sroa.2.0..sroa_idx5 to <2 x i64>*
  store <2 x i64> %3, <2 x i64>* %4, align 8
  %newstruct.sroa.4.0..sroa_idx7 = getelementptr inbounds [4 x i64], [4 x i64]* %0, i64 0, i64 3
  store i64 10, i64* %newstruct.sroa.4.0..sroa_idx7, align 8
  ret void
}

julia> @code_llvm modstruct2(MyStruct(1, 2, 3, 4))
;  @ REPL[4]:1 within `modstruct2`
define void @julia_modstruct2_208([4 x i64]* noalias nocapture noundef nonnull sret([4 x i64]) align 8 dereferenceable(32) %0, [4 x i64]* nocapture noundef nonnull readonly align 8 dereferenceable(32) %1) #0 {
top:
;  @ REPL[4]:2 within `modstruct2`
; ┌ @ /Users/ronan.arraes/.julia/packages/ConstructionBase/JFKjZ/src/ConstructionBase.jl:131 within `setproperties`
; │┌ @ /Users/ronan.arraes/.julia/packages/ConstructionBase/JFKjZ/src/ConstructionBase.jl:213 within `setproperties_object`
; ││┌ @ /Users/ronan.arraes/.julia/packages/ConstructionBase/JFKjZ/src/ConstructionBase.jl:103 within `getproperties`
; │││┌ @ broadcast.jl:903 within `materialize`
; ││││┌ @ broadcast.jl:1118 within `copy`
; │││││┌ @ ntuple.jl:69 within `ntuple`
; ││││││┌ @ ntuple.jl:72 within `macro expansion`
; │││││││┌ @ broadcast.jl:1118 within `#31`
; ││││││││┌ @ broadcast.jl:682 within `_broadcast_getindex`
; │││││││││┌ @ broadcast.jl:709 within `_broadcast_getindex_evalf`
; ││││││││││┌ @ Base.jl:37 within `getproperty`
             %memcpy_refined_src = getelementptr inbounds [4 x i64], [4 x i64]* %1, i64 0, i64 1
; └└└└└└└└└└└
;  @ REPL[4]:3 within `modstruct2`
  %newstruct.sroa.0.0..sroa_idx = getelementptr inbounds [4 x i64], [4 x i64]* %0, i64 0, i64 0
  store i64 10, i64* %newstruct.sroa.0.0..sroa_idx, align 8
  %newstruct.sroa.2.0..sroa_idx5 = getelementptr inbounds [4 x i64], [4 x i64]* %0, i64 0, i64 1
;  @ REPL[4]:2 within `modstruct2`
; ┌ @ /Users/ronan.arraes/.julia/packages/ConstructionBase/JFKjZ/src/ConstructionBase.jl:131 within `setproperties`
; │┌ @ /Users/ronan.arraes/.julia/packages/ConstructionBase/JFKjZ/src/ConstructionBase.jl:217 within `setproperties_object`
; ││┌ @ REPL[2]:2 within `MyStruct`
     %2 = bitcast i64* %memcpy_refined_src to <2 x i64>*
     %3 = load <2 x i64>, <2 x i64>* %2, align 8
; └└└
;  @ REPL[4]:3 within `modstruct2`
  %4 = bitcast i64* %newstruct.sroa.2.0..sroa_idx5 to <2 x i64>*
  store <2 x i64> %3, <2 x i64>* %4, align 8
  %newstruct.sroa.4.0..sroa_idx7 = getelementptr inbounds [4 x i64], [4 x i64]* %0, i64 0, i64 3
  store i64 10, i64* %newstruct.sroa.4.0..sroa_idx7, align 8
  ret void
}

Again, I am no compiler expert, but it really seems to me that the compiler is using the same object to update the two values.

[ronisbr]

First the problem was the LLVM output that was "huge", now it is the allegedly very high compile times (that Julia 1.10 is handling pretty well). So, Ok, do what you want. However, for everybody else that is reading this thread, just use Accessors.jl if you want to develop allocation-free code without compromising readability. I am doing it for a long time, and it is awesome!

[chakravala]

If this project isn't as stupid and terrible as it sounds, then you ought to make that clear in the Readme, otherwise people will glance at it and consider it a terrible idea. Glancing at the Readme doesnt give much confidence, and the popularity of it makes me think these are all lazy and bad programmers.

…

On Wed, Feb 7, 2024, 1:12 PM Alexander Plavin ***@***.***> wrote: It's built on ConstructionBase.setproperties that provides an efficient way to set multiple properties. Feel free to use that function! — Reply to this email directly, view it on GitHub <#133 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMFOEFUHBDKBJNP2H3NE4TYSO7YPAVCNFSM6AAAAABC6JCIUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZSGYYDSNRWGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jw3126]

@chakravala I am curious why you are interested in this package.

[chakravala]

I saw it on my github feed so i checked it out and told you what it looks like to me, I wouldnt want to use packages that depend on this package if it's less efficient and lazy design if you dont care about my feedback then ignore it, in the future somebody else will see your project Readme and judge it as I did

…

On Wed, Feb 7, 2024, 4:23 PM Jan Weidner ***@***.***> wrote: @chakravala <https://github.com/chakravala> I am curious why you are interested in this package. — Reply to this email directly, view it on GitHub <#133 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMFOEHY7HSEHSN3BS2T6MTYSPWGJAVCNFSM6AAAAABC6JCIUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZSHE2TQMBZGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[chakravala]

To me, that looks like a huge LLVM output. When constructing an object, should be minimal LLVM code. All you're doing is assigning values to an object, but I see a giant wall of text of LLVM code. And all you have to do is just construct a new object the standard way with a regular constructor. Are people really this lazy, that they can't use constructors regularly? I think this package seems unnecessary and now you're generating this huge dump of LLVM code instead of just simply calling the constructor how it's meant to be used.

[ronisbr]

You are definitely not understanding the behavior. This LLVM output is not huge, it is minimal! Just remove the comments (those lines started by ;) and you will see. Just for comparison, here is the output of calling the constructor as you said:

function modstruct3(s::MyStruct)
    return MyStruct(10, s.b, s.c, 10)
end

julia> modstruct3(MyStruct(1, 2, 3, 4))
MyStruct(10, 2, 3, 10)

julia> @code_llvm modstruct3(MyStruct(1, 2, 3, 4))
;  @ REPL[16]:1 within `modstruct3`
define void @julia_modstruct3_272([4 x i64]* noalias nocapture noundef nonnull sret([4 x i64]) align 8 dereferenceable(32) %0, [4 x i64]* nocapture noundef nonnull readonly align 8 dereferenceable(32) %1) #0 {
top:
;  @ REPL[16]:2 within `modstruct3`
; ┌ @ Base.jl:37 within `getproperty`
   %memcpy_refined_src = getelementptr inbounds [4 x i64], [4 x i64]* %1, i64 0, i64 1
; └
  %newstruct.sroa.0.0..sroa_idx = getelementptr inbounds [4 x i64], [4 x i64]* %0, i64 0, i64 0
  store i64 10, i64* %newstruct.sroa.0.0..sroa_idx, align 8
  %newstruct.sroa.2.0..sroa_idx5 = getelementptr inbounds [4 x i64], [4 x i64]* %0, i64 0, i64 1
; ┌ @ REPL[2]:2 within `MyStruct`
   %2 = bitcast i64* %memcpy_refined_src to <2 x i64>*
   %3 = load <2 x i64>, <2 x i64>* %2, align 8
; └
  %4 = bitcast i64* %newstruct.sroa.2.0..sroa_idx5 to <2 x i64>*
  store <2 x i64> %3, <2 x i64>* %4, align 8
  %newstruct.sroa.4.0..sroa_idx7 = getelementptr inbounds [4 x i64], [4 x i64]* %0, i64 0, i64 3
  store i64 10, i64* %newstruct.sroa.4.0..sroa_idx7, align 8
  ret void
}

See? Now, imagine how much typing and error prone would be changing a value of an immutable structure with 100 parameters compared to @reset s.p = <new value>. That's why Accessors.jl is awesome! IMHO, it should be in Base.

[chakravala]

Have you considered that this slows down compile times? Many packages I developed have problems with increasing compile times, which I try to trim down by clever design and non-lazy programming. Imagine you have some critical piece of code which needs to be compiled many many times, and you're slowing down compilation with all this crap because it has to expand the macro and do all these extra steps for compilation. No, this seems very lazy programming, and I wouldn't want to depend on packages which do lazy programming, potentially causing very long cumulative compilation times. Sometimes I write code which has to recompile the same thing in many different ways, and I would want Julia to start up fast and not spend extra time compiling things by expanding macros which werent ever needed. Instead of being lazy, you could have simply used a regular constructor instead of increasing compiler overhead. You have no idea how much compiler overhead this could cause downstream, which could have been avoided and compiled faster. It could be a huge amount, I know compile times can be improved with non-lazy programming.

[chakravala]

Hilarious. You could just write `MyStruct(s.a, 10, s.c , 11)` and that is both shorter and allocation free and doesn't produce additional compiler overhead. Now imagine that `a,b,c,d` have variable types and need to be recompiled several thousand times with different types. Without Accessors.jl it will compile quicker than if it had to expand a bunch of macros and optimization passes to in hope to attempt to make it allocation free. Without Accessors.jl it is guaranteed that it is allocation free and no additional compiler overhead, no additional compiler optimization passes, etc. Your code is lazy and now the compiler has to work extra hard to make things happen allocation free, instead of just directly writing the allocation free code yourself. Your laziness is now transferred to the compiler. Because you were so lazy, now on ever user's computer the compiler has to work to optimize a simple constructor, which you could have spent 10 seconds more writing the code for, avoiding the extra compiler compute which now wastes energy, time, electricity, etc all because you were lazy.

[shayandavoodii]

@chakravala, you can either contribute to enhance projects in a respectful manner or walk away. You're just criticizing without any positive effort to tackle the issue that you're talking about and talking like the maintainer owes you! How rude you are!

[chakravala]

The word "lazy" is a formal term in programming and isn't offensive. If you are offended by the concept of "lazy programming" then you probably don't know what it means. Lazy programming means that there is some latent feature in the code which isn't exectuted until later on, when it's needed. In this case, you are doing lazy programming by deferring the generation of "allocation free" code to the compiler, instead of spending the extra effort on it yourself as the programmer. If if offends you that this is classified as lazy programming, then perhaps you need to reconsider why you're using this package.

[ronisbr]

So, technically, you are also doing "lazy programming" by writing in Julia! Why don't just write in machine code and avoid "laziness" to the extreme!

[aplavin]

We appreciate discussions that stay on topic and don't become too personal. Unfortunately, I don't see this one leading to anything constructive.
Please feel free to open more specific and/or actionable issues!