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:-)
   - lesson learned (remembered): use asynchronous profiling to avoid 
   safepoint bias
   - when I do that without the workaround it's clear that the addition is 
   50% of the observable work in that method, the Numbers.num Long.valueOf() 
   calls the other 50% - so eliminating the cast doesn't make everything free


Pete Windle
On Monday, May 16, 2022 at 12:40:07 AM UTC+1 Alex Miller wrote:

> 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