Seems to me that the problem is the unit test is too simple-minded to
handle the occasional reorderings that occur. I see no reason to have a
particular order of the element be part of the contract of
asFormatString(). Who cares what the order is? How about just fixing the
unit test?
Jeff
Sean Owen wrote:
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.
