I was talking about the one in cvs. I was trying to point out that there are other classes that suffer from the same problem that you are fixing and that there are other problems with one of the LRU implementations. See the other emails.
Cheers, Aaron > -----Original Message----- > From: Michael A. Smith [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 01, 2002 10:46 AM > To: Jakarta Commons Developers List > Subject: RE: [collections][PATCH] SequencedHashMap violates Map contract, > has poor performance -- BufferCache, SequencedHastable, MRUMap and LRUMap > . > > On Fri, 1 Feb 2002, Aaron Smuts wrote: > > The SequencedHashMap has the same problem with the LinkedList remove > > operation which executes in O(N) time as BufferCache, SequencedHastable, > and > > MRUMap. > > Umm... I'm a bit confused. Are you referring to the SequencedHashMap > that exists in current CVS, or the version I posted (I'm not sure because > the subject starts with the same subject as my recent mail containing a > patch for SequencedHashMap and quotes one of my mails). > > If you're referring to the current SequencedHashMap in CVS, then yes, it > has O(n) performance. I mentioned that fact in my email, and is one of > the things fixed in my implementation. > > If you're referring to the version in my patch, then I don't see how it > executes in O(n). > > > The LRUStore I put in stratum looks similar to what you are working on. > > ah, maybe you were just reiterating the problems with existing CVS > version. Stratum is some component in turbine, right? I'm not that > familiar with it. I did see your post here about it though, and plan on > commenting on it this evening or tomorrow when I have some more time. > > > LRUMap in Collections looks pretty good. I'm going to test it. > > I haven't looked over that yet. It's on my list. I'll comment on the > rest of your mail after I review it either this evening or tomorrow. > > regards, > michael > > > > -- > To unsubscribe, e-mail: <mailto:commons-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:commons-dev- > [EMAIL PROTECTED]>
