The autoboxing process mostly. When ints are autoboxed and unboxed, there is a performance hit because it does method invocations and instantiation. Autoboxing for some values will hit a cache to reduce instantiation overhead, but I think that is only for numbers < 256.
I've found that Lists, Maps and Sets that work directly on primitives reduce overhead quite a bit by removing the instantiation for the autoboxing and the method invocation for unboxing. Of course, it all depends on the size and volume of access. I have a Trie that used a Map<Character, Trie> internally and I switched it to a primitive char map and it increased performance by about 20-30% and reduced memory consumption as well. -bp On Nov 2, 2010, at 11:41 AM, Martin Gainty wrote: > > Brian > > how does primitive collections implementation perform better than JDK > collections? > > thanks, > Martin > ______________________________________________ > please do not alter or disrupt this transmission. thank you > > > > > >> Subject: Re: [Primitives] Does anyone use this? >> From: [email protected] >> Date: Tue, 2 Nov 2010 11:32:01 -0600 >> To: [email protected] >> >> I would assume once you get out of the autoboxing caches the performance >> will get even worse. It really depends on the application, but I've found a >> number of spots where primitive collections work much better than autoboxing >> and JDK collections. >> >> -bp >> >> >> On Nov 2, 2010, at 11:25 AM, James Carman wrote: >> >>> Yet another dependency to add to the mix. >>> >>> On Tue, Nov 2, 2010 at 1:17 PM, Cogen, David - 1008 - MITLL >>> <[email protected]> wrote: >>>> >>>> ________________________________________ >>>> From: [email protected] [[email protected]] On >>>> Behalf Of James Carman [[email protected]] >>>> Sent: Tuesday, November 02, 2010 12:30 PM >>>> To: Commons Users List >>>> Subject: Re: [Primitives] Does anyone use this? >>>> >>>> Premature optimization with JDK5. I'd say stick to the JDK classes if >>>> you can and only try to beef up space/performance if you need to. >>>> >>>> >>>> Normally I agree about evils of premature optimization. But ArrayListInt >>>> is practically a drop-in replacement for ArrayList<Integer> and I see no >>>> reason not to use it if it is supported and reliable. >>>> >>>> My test of 2 billion accesses (reads and writes) ran in 35% of the time >>>> when I used ArrayListInt vs. ArrayList<Integer>. >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
