Funny, Arrays.copy() for HashMap... but something similar... Anyway, I use same values for initial size and max size, to be safe... and to have OOP at startup :)
> -----Original Message----- > From: Fuad Efendi [mailto:f...@efendi.ca] > Sent: February-12-10 6:55 PM > To: solr-user@lucene.apache.org; yo...@lucidimagination.com > Subject: RE: For caches, any reason to not set initialSize and size to > the same value? > > I always use initial size = max size, > just to avoid Arrays.copyOf()... > > Initial (default) capacity for HashMap is 16, when it is not enough - > array > copy to new 32-element array, then to 64, ... > - too much wasted space! (same for ConcurrentHashMap) > > Excuse me if I didn't understand the question... > > -Fuad > http://www.tokenizer.ca > > > > > -----Original Message----- > > From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik > > Seeley > > Sent: February-12-10 6:30 PM > > To: solr-user@lucene.apache.org > > Subject: Re: For caches, any reason to not set initialSize and size to > > the same value? > > > > On Fri, Feb 12, 2010 at 5:23 PM, Jay Hill <jayallenh...@gmail.com> > > wrote: > > > If I've done a lot of research and have a very good idea of where my > > cache > > > sizes are having monitored the stats right before commits, is there > > any > > > reason why I wouldn't just set the initialSize and size counts to > the > > same > > > values? Is there any reason to set a smaller initialSize if I know > > reliably > > > that where my limit will almost always be? > > > > Probably not much... > > The only savings will be the 8 bytes (on a 64 bit proc) per unused > > array slot (in the HashMap). > > Maybe we should consider removing the initialSize param from the > > example config to reduce the amount of stuff a user needs to think > > about. > > > > -Yonik > > http://www.lucidimagination.com >
