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.
