Mark DePristo 0f04485c24 NanoScheduler optimization: don't use a PriorityBlockingQueue for the MapResultsQueue ... -- Created a separate, limited interface MapResultsQueue object that previously was set to the PriorityBlockingQueue. -- The MapResultsQueue is now backed by a synchronized ExpandingArrayList, since job ids are integers incrementing from 0 to N. This means we avoid the n log n sort in the priority queue which was generating a lot of cost in the reduce step -- Had to update ReducerUnitTest because the test itself was brittle, and broken when I changed the underlying code. -- A few bits of minor code cleanup through the system (removing unused constructors, local variables, etc) -- ExpandingArrayList called ensureCapacity so that we increase the size of the arraylist once to accommodate the upcoming size needs		2012-12-24 13:35:56 -05:00
..
net/sf	Cleanup of VCF header lines and constants, BCF2 bugfixes	2012-06-21 15:16:31 -04:00
org/broadinstitute	NanoScheduler optimization: don't use a PriorityBlockingQueue for the MapResultsQueue	2012-12-24 13:35:56 -05:00