Comments on Daniel Schneller's Blog: Collection Performance - Don't become too lazy

Hi! Interesting article. I'm guessing the ori...

2011-01-06T18:44:17.418+01:00

Hi!

Interesting article. I'm guessing the original code is not copy/pasted since it appears to be broken (in addition to being very inefficient). Specifically, tempCount == chunkSize will never be true inside the loop, and also I suspect the references to "tCurrent" should really refer to the local declared as "current"?

Regards,
Daniel K

Ultimately removeAll will be doing something along...

2010-11-17T15:58:31.193+01:00

Ultimately removeAll will be doing something along the lines of a nested iteration, depending on the underlying List implementation used. If allIter.remove is used, none of that repeated iteration is required. Should result in some improvement, although I'd agree probably not to the extent of using indexes.

Even though I did not try this, it would probably ...

2010-11-17T15:44:30.930+01:00

Even though I did not try this, it would probably be the same - as removeAll simply iterates the passed collection and calls remove for each item, the amount of rearranging the backing store would be needed. Perhaps a subtle difference, depending on whether the iterator internally already knew the array index or not, maybe saving that lookup. But that lookup is generally hardly measurable in lists of that size.

I'd be interested to know what the difference ...

2010-11-17T11:28:21.823+01:00

I'd be interested to know what the difference in timings would be if (using the original code) every time result.add was called, you also called allIter.remove(), rather than doing the removeAll at the end?

Good to know.... Sometime

2010-11-17T09:31:39.955+01:00

Good to know.... Sometime