Yeah I'm not really worried about the boxing/unboxing yet, since it is buying some code simplicity, though I took the liberty of eliminating boxing where it is redundant, like: int c = new Integer(someString) versus int c = Integer.parseInt(someString)
I agree we can go to that trouble if it becomes clear it is non-trivially slowing down the code. It may well. I was more interested in more obvious wins by adjusting use of some Collections API methods as in dot(). I'd be happy to hack away on this but I am hesitating about doing anything but trivial changes to code others are working on, while it might be looked at as premature. If it's viewed as a good thing I can go for it. Hows about changing asFormatString() to sort output? was that the right solution or is its output order not guaranteed. I could take care of it. On Fri, Aug 8, 2008 at 2:45 PM, Ted Dunning <[EMAIL PROTECTED]> wrote: > Worrying about small effects like iterating over keys or entries should be > made moot by just switching to a dedicated primitive based hash table. > Trove has a nice implementation, but I believe the license would prevent > it's use. Colt has another, not quite as nice implementation that is fast > and I think it comes under a BSD license. It is also very easy to hack a > special purpose structure into place.
