Hi Alex,
- the ^void is necessary to get the method signature right for it to
compile at all
- *the nil workaround "works" in that decompilation shows the method
body with the addition only, no cast - thank you*
- ...but makes a smaller difference to my overall execution time:-)
I don't think that void type hint is going to do anything there. The
deftype impl of apply here will (has to by Java requirements) return void
here. There is a gap here I think where the return gets needlessly boxed.
You might try just putting a nil expr after the set! as a workaround.
In any c
I wondered if this would work if I handed the result off to a helper class
public class VoidHelper {
public static void voidLong(long x) {}
}
If this somehow improved the code path, with inlining etc it would be
basically free.
...but the generated code gets worse.
public void apply(fi
Definitely in the same wheelhouse, but upgrading to 1.11.1 shows the same
behaviour - as expected, because this is not an InstanceMethodExpr.
https://github.com/clojure/clojure/blame/master/src/jvm/clojure/lang/Compiler.java#L1831-L1842
is the logic for StaticMethodExpr.
AssignExpr hands off t
This reminds me of a bug that I believe Ghadi fixed for 1.11,
https://clojure.atlassian.net/browse/CLJ-2621
Don’t know if that helps much, though.
Erik.
--
i farta
> 15. mai 2022 kl. 14:11 skrev pete windle :
>
> Hey, I'm trying to work on some performance sensitive code using Clojure
>
Hey, I'm trying to work on some performance sensitive code using Clojure
together with the Carrotsearch HPPC library. I've come up against a weird
behaviour of set! in conjunction with primitive maths.
This example is a toy problem not a production problem, but there are
things I might not be h
