"Ned Konz" <ned at bike-nomad.com>
provided a correction to WeakSet>>collect:

The problem is that Set does
    newSet := Set new: self size.
    array do: [:each | each ifNotNil: [newSet add: (aBlock value: each)]].
    ^newSet
instead of using the inherited Collection method
    newCollection := self species new.
    self do: [:each | newCollection add: aBlock value: each)].
    ^newCollection

Now the funny thing is that the Collection>>collect: method
 - would give the right result for WeakSet
 - but this is NOT a case for super super, because it would ALSO
   give the right result for Set.

so perhaps the simplest fix of all would simply be to delete the
Set>>collect: method (which may, after all, over-allocate).

It's high time Sets had a redesign anyway.  The nil object has
perfectly workable #= and #hash methods, so why _can't_ it be an
element of a Set?  It makes perfect sense.

For example, Set could have a Dummy class variable, lazily initialised
to be (for example) Object new, and that could be used instead of nil.

Squeak 3.0 of 4 February 2001, latest update: #3552,
running on a 266MHz PowerMac G3 with MacOS 8.6 and 64MB of memory.

|a|
[a := Set new. 1 to: 1200 do: [:i | a add: i]] timeToRun
    ==> 39
"with the same setup"
[a collect: [:each | each]] timeToRun
    ==> 24
"with Set>>collect: removed"
[a collect: [:each | each]] timeToRun
    ==> 45

so that's a fairly strong argument for retaining the code in Set.
Or would be, except that

[a select: [:each | true]] timeToRun
    ==> 44

If we can tolerate that time from #select:, we can tolerate it from
#collect:, no?