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 case, we should definitely get a ticket filed and track this down.

On Sunday, May 15, 2022 at 7:11:31 AM UTC-5 pete windle wrote:

> 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 harder to do at work w/Clojure.
> I have a com.carrotsearch.hppc.LongLongHashMap and I wish to sum the 
> contents of the map. They provide a com.carrotsearch.hppc.LongLongProcedure 
> where an apply method is called for each k, v.
> Thence:
> (defprotocol ValueRetriever
>   (get-value [this ^LongLongHashMap memory]))
> (deftype ValueAdder [^{:unsynchronized-mutable true} ^long total]
>   LongLongProcedure
>   (^void apply [this ^long k ^long v]
>    (set! total (unchecked-add total v)))
>   ValueRetriever
>   (get-value [this memory] (set! total 0) (.forEach memory this) total))
> To a first approximation all of the time spent summing the map is in the 
> apply method as expected, however when I profile it with YourKit every 
> sample taken is actually in clojure.lang.Numbers.num. Using the extremely 
> handy *clj-java-decompiler *library I can try to see what's happening, 
> and it looks like we're attempting to box the return value from set!
>     public void apply(final long k, final long n) {
>         Numbers.num(this.total += n);
>     }
> Is there some technique I can use to stop the return value from set! being 
> boxed (before the box is discarded to the void)?
> I do have real use cases where a rather tight aggregation loop will be 
> called for many millions of values and I'd prefer not to incur this cost.
> Workaround is obviously to write the aggregators in Java but that's 
> strongly not preferred, at the point I'm mixing modes I might as well write 
> the whole core in Java.
> Cheers,
> Pete Windle

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
For more options, visit this group at
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to