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.