can this be of interest? ---------- Forwarded message ---------- From: Ralph Boland <rpboland@gmail.com> Date: Tue, Jun 23, 2009 at 6:47 PM Subject: [squeak-dev] Faster Sets Project: Response to comments. To: squeak-dev@lists.squeakfoundation.org First, as suggested I have changed the license to MIT. The follow suggestion was made: if you would like your new implementation to replace the old one in Squeak, you might want to write unit tests. These tests ensure that there is no problem. FasterSets includes only one new class used for measuring the performance improvement of the other changes. All of the remaining improvements are changes to class Set and its many subclasses. Allow me to consider 4 subsets of the classes Set and all of its subclasses. 1) (Set WeakIdentityKeyDictionary Dictionary) These classes have unit tests. I have run them and they all pass with FasterSets. 2) ComparesCountingSet This is the only new subclass of Set that I have added. It only measures performance and will disappear once the FasterSets project is incorporated into Squeak. Is is exercised sufficiently in doing its performance measurements that I do not feel that it needs a unit test. 3) (WeakKeyDictionary IdentityDictionary WeakSet KeyedSet PluggableDictionary WeakKeyToCollectionDictionary WeakValueDictionary PluggableSet MethodDictionary LiteralDictionary IdentitySet SystemDictionary KeyedIdentitySet) These are the subclasses of Set that have no unit tests. If unit tests for these classes are added to Squeak I will run FasterSets code against them and fix any FasterSet bugs I find. I have no desire to write them though. I don't know what most of them do and feel these tests are best written by someone who does. Even if all these test existed and passed with FasterSets it wouldn't establish that FasterSets has not introduced bugs. I have tested them in a rather poor way. I have been running Squeak using FasterSets since Squeak 3.6 and, as it happens, my application uses Set and a number of its subclasses A LOT! So some of these subclasses should be considered reasonably well tested (Set, Dictionary,IdentitySet). The others have been tested to the extent that they have been exercised by my using Squeak. However most of the work I do is algorithmic (finite state machine construction mostly) and so I'm sure large sections of Squeak are not exercised or not exercised very well by me. So there is real potential that anyone who loads FasterSets into their image will discover bugs and I recommend caution to anyone who loads FasterSets. Fixing bugs though should be easy. I will fix any reported to me or give permission to anyone who wants to to make and install the fix themselves. This may all sound very alarming but keep in mind that FasterSets actually contains very little code and not very complicated code at that. Caution is warranted because the classes modified are all low level and some are extensively used. The real problem though is, I suspect, some are not extensively used. 4) (WeakKeyToCollectionDictionary WeakValueDictionary PluggableSet LiteralDictionary SystemDictionary KeyedIdentitySet) These subclasses of Set have not been modified in FasterSets; in other words most have. Even the unmodified ones have superclasses that have been modified so all need to be tested. In fact the only reason for classes not being modified is because they inherit the necessary added behavior. Thus in my opinion the only classes that have been adequately tested are Set, Dictionary, and IdentityDictionary. If someone wants to claim that the five tests run by WeakIdentityKeyDictionaryTest are sufficient to claim WeakIdentityKeyDictionary is adequately tested I can add it to the list?. If anyone can send me a list of classes adequately tested just by running Squeak I will add them to the list. If I ever get to the point that all subclasses of Set are claimed to be adequately tested by somebody I will make a posting state this and who claims the tests are adequate. If anybody wishes to write any of the missing unit tests and add them to FasterSets until such time as they can be added to Squeak such efforts are most welcome. A final comment. I am most interested in getting FasterSets incorporated into Squeak and that means having FasterSets being properly tested. However I don't consider myself to be the best person to do this work though I will help if I can. The best persons to do so are those who can load FasterSets into their image and not be too upset if they get blown out of the water! They also must have images they can claim exercises one or most of the Set subclasses adequately. Regards, Ralph Boland On Sat, Jun 20, 2009 at 3:21 PM, Ralph Boland<rpboland@gmail.com> wrote:

I finally released my first project to the www.squeaksource.comrepository. Its called FasterSets. It makes sets faster by not doing compares during grow operations which makes adding to sets use about 14% fewer compares on average during an add: operation assuming no deletions or preallocation of space before adding elements. Code for measuring performance is included. See Class FastSetsComment.

Comments welcome.

I consider the project complete but am willing to make changes as required or give permissions for others to do so or to take over the project.

My hope is that this code will be incorporated into Squeak someday. I have not signed any release forms to allow this but am willing to do so.

The project runs in Squeak 3.10.2 but can be easily modified to work in previous versions of Squeak.

Regards

Ralph Boland