Lenses still cause a performance overhead around 2x comparing to hand written copy (as measured with jmh)
Since Goggles is generating code anyway, could we gain a speedup by directly generating the underlying code for chains of .name optics?
Getters would fuse into a single Getter with direct method calls: foo.bar.baz
Setters would fuse into nested copy calls: foo.copy(bar = foo.bar.copy(baz = <new thing>))
Lenses could fuse both. (Don't forget that lens mode might produce Isos as well, pending #26!)
We would have to examine the produced bytecode to ensure parsimony, and we would have to introduce benchmarks to demonstrate that sufficiently impressive speedups occur in practice.
Since we would still want to provide the illusion of the segments being separate optics (ie in the fancy error message table), some clever software engineering might be required to maintain a modular design within the macro code.
@julien-truffaut mentioned that:
Since Goggles is generating code anyway, could we gain a speedup by directly generating the underlying code for chains of
.name
optics?Getters would fuse into a single Getter with direct method calls:
foo.bar.baz
Setters would fuse into nested copy calls:foo.copy(bar = foo.bar.copy(baz = <new thing>))
Lenses could fuse both. (Don't forget thatlens
mode might produce Isos as well, pending #26!)We would have to examine the produced bytecode to ensure parsimony, and we would have to introduce benchmarks to demonstrate that sufficiently impressive speedups occur in practice.
Since we would still want to provide the illusion of the segments being separate optics (ie in the fancy error message table), some clever software engineering might be required to maintain a modular design within the macro code.