You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apparently Integer is an immutable class, so instead of changing the int it is holding, a new object is allocated with the new int (I haven't looked further into why this is the case, but that is not the focus of these benchmarks).
91
-
This explains the slowdown of a factor 2.2-2.5 quite well, as each addition causes the creation of a new object leaving the old object to be garbage collected.
101
+
This explains the slowdown of a factor 2.2--4.3 quite well, as each addition causes the creation of a new object leaving the old object to be garbage collected.
102
+
103
+
For Short its even worse, its additional overhead compared to Integer is described in [Section 3 to 2](#3to2).
92
104
93
105
##From 4 to 2
94
106
The first difference from 4 and 5 to 1,2 and 3 is that primitive data types are used instead of their corresponding wrapper classes.
@@ -97,6 +109,7 @@ This gives us two advantages:
97
109
* The size of an int is 4 bytes, where an Integer takes up 32 bytes of heap space, so simply an array of ints has less data to be crunched. Check out http://btoddb-java-sizing.blogspot.dk/ for a more indepth analysis.
98
110
* The method `intValue()` is no longer called to extract the int, saving an operation.
99
111
112
+
<aname="3to2"></a>
100
113
##From 3 to 2
101
114
When short is only half the size of an int, why does it perform worse?
102
115
It is even accumulated in a short to avoid any conversion, well think again.
@@ -127,10 +140,15 @@ This one should now be obvious.
127
140
To avoid the `i2s` operation the data type of the accumulator variable is changed to an int.
128
141
We now get all the benefits of native addition, no method calling and less data to fetch from memory.
129
142
130
-
##Conclusion
143
+
144
+
##Memory
131
145
As you might have noticed the use of ArrayLists or multidimensions haven't been mentioned so far as obvious sinners, because for my tests their usage didn't influenced the performance.
132
-
Of course there is a little extra memory consumption of 2D arrays as each entry in the first dimension is a pointer to a second dimension.
133
-
So an `Integer[2000][2000]` takes up 62,5 kb extra memory in contrast to a `Integer[2000*2000]`.
134
-
Here the [Trove library](http://trove.starlight-systems.com/) offers high performance collections, e.g. ArrayLists that works on primitive data types instead of objects.
146
+
Of course there is an extra memory consumption of 2D arrays as each entry in the first dimension is a pointer to a second dimension.
147
+
148
+
As far as I have been able to measure using some [code by Twitter](https://github.com/twitter/commons/blob/master/src/java/com/twitter/common/objectsize/ObjectSizeCalculator.java) a 2D arrayList of 2000x2000 Integers consumes `46.9 kb` more memory than a 2D array of 2000 Integers, which consumes `39 kb` more memory than a 1D array of Integers.
149
+
150
+
The [Trove library](http://trove.starlight-systems.com/) offers high performance collections, e.g. ArrayLists that works on primitive data types instead of objects.
151
+
152
+
##Conclusion
135
153
136
-
Explore your language and if doubt which way to do it (disregardnig readability), benchmark to know which way is faster and disassemble to get insight *why* one way is faster.
154
+
Explore your language and if doubt which way to do it (disregardnig readability), benchmark to know which way is faster and disassemble to get insight *why* one way is faster. Trying to be "smart" can end up hurting your performance
0 commit comments