Fwd: [squeak-dev] Faster Sets Project: Response to comments.

---------- Forwarded message ----------
From: Ralph Boland <[hidden email]>
Date: Tue, Jun 23, 2009 at 6:47 PM
Subject: [squeak-dev] Faster Sets Project: Response to comments.
To: [hidden email]


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<[hidden email]> wrote:
> I finally released my first project to the www.squeaksource.com repository.
> 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
>
>