Fork me on GitHub

What is the point of aset-int ? When should I use it instead of aset ?

Alex Miller (Clojure team)20:02:59

aset-int is specifically for int[]

Alex Miller (Clojure team)20:02:14

aset is for arrays of objects


ah, so aset-int is faster (and throws on type error)?


nah, both throw on type error, I guess; so, just faster


looking at the source for aset-int, it seems its specifically wrapping this (. Array (setInt array id (int val))) so 1. Specifically using setInt instead of a generic setting function (so if there's any additional value in doing this when you know its applicable, there's that. Unfortunately I don't know off the top of my head the benefits there) 2. Being sure to coerce the value you're inputting to an int first


Yea I see, one seems to just be wrapping Array.set(Object []array, int index, Object value) and the other Array.setInt(Object array, int index, int value) , so I can at least say 1. As it is, Array.set is defined by checking if you have a generic Object[] array or a primitive array such as double[] or our int[], and dispatching on this so that if you do, say, have an int[] its going to forward everything to that setInt function. Calling setInt outright skips this step 2. I just tested the two, and running set 1000 times to set an int in an array of ints yields a runtime of 2688073 nanoseconds, and setInt yields 471343 ns, about 18% runtime of the runtime / an 83% speedup. Of course, I did a quick and dirty test, I'd like to change some things to make sure there's no optimization or anything I wouldn't think of going on (as I just called set and setInt on the same array, and same value, 1000 times) that would skew the results of the test, but yea


anything for the battousai


@zdot101 but, but. (aset ^ints a i v) is actually much (I don't know, twice, maybe?) as fast as (aset-int ^ints a i v)


so there seems to be absolutely no point in aset-int, at least for performance


I do recall there being something strange about the performance of aset-int from years back, but I don't recall digging into the implementation details to see if it was easy to figure out why that was so. aset with appropriate type hints seemed like the way to go, from what I recall then. Performance measurements of your actual application are always a good recommendation, if you care about performance.


If someone was motivated, using Criterium to measure performance differences of some uses of aset vs. aset-int and/or some other aset-* functions, ones that they had checked did not cause reflection (because then performance is guaranteed to be horribly bad), and publish the results in a small Github repo, with a link to them from pages for the aset* functions, that would be helpful.


Even better if you can figure out why the performance difference exists.


Not that figuring out performance differences in implementations of different Clojure functions is a typical Clojure beginner activity -- there isn't any reason an interested beginner can't do the measurements, and perhaps also figure out the reasons why the performance differences exist.