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
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
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 
https://groups.google.com/d/msgid/clojure/854262ad-34ec-4cb1-9760-0329fdbf714cn%40googlegroups.com.

Reply via email to