Well I recall a few years back I rewrote the new: logic to be more  
stream lined and suggested the usage of a
table of integers to be used for the object hash, versus calculating  
them.

See hashBits, a lazy way from july of 2003

"Change Set:		allocateNoFillHashTable-JMM
Date:			15 July 2003
Author:			johnmci at smalltalkconsulting.com

Two changes, the one being reworking the allocation calls to allow  
for small and normal object allocation without initializing to nilObj  
or 0, or some value. This allows calls that say create floats to get  
back an allocated object, then fill in with the data. Beware one does  
not do a GC event before the object is fully created. The other major  
change is to use a random shuffled 4096 element array to fetch the  
identity hash from versus doing a calculation"



On 5-Jan-06, at 1:08 PM, Bryce Kampjes wrote:

> Andreas Raab writes:
>> Bryce Kampjes wrote:
>>> If you're trying to speed up object creation for a small frequently
>>> used object then writing a custom primitive to quickly create the
>>> object will be much easier. Squeak's general new primitive is very
>>> slow.
>>
>> Do you have any evidence towards that end? It would be simple to add
>> specialized versions of primitiveNew to the mainstream VMs if it  
>> makes a
>> real difference.
>
> John McKintosh measured it, I haven't yet profiled the VM
> seriously. I've noticed that opening a large Morphic explorer seems to
> be spending 50% of it's time creating points, this is my
> interpretation of a Squeak profile. I've also read through the Slang
> code for new.
>
> It's enough empirical evidence for me to act.
>
> Bryce
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===