On the same lines of optimization - I added some optimizations for SparseVector. Especially for operators like minus, plus and divide. Please look at mahout-67, mahout-66 patches for the same. The methods in AbstractVector were getting called for minus, plus and divide where it was iterating thru all the keys irrespective of whether the key contains empty value or not.
Thanks Pallavi -----Original Message----- From: Sean Owen [mailto:[EMAIL PROTECTED] Sent: Saturday, August 09, 2008 12:28 AM To: [email protected] Subject: Re: asFormatString tests fail 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.
