Chris,

I don't think trying to optimize LargeInteger comparisons or arithmetic
will likely get you very far (though there might be some room for
improvement there).  You might be able to something using ByteArrays
with primitive support instead...make your oids 64 bits, and do 1 or 2
word comparisons in your primitive...that might be a little faster.

But, it looks to me like the issue is more about scaling the
dictionaries.  The reason that the comparison is consuming such a large
percentage of your time is that it is being called many times (not that
it itself takes an overly long time to perform).

In fact, the profiling results that you have for the 30 second test are
probably not valid at all for the 5 hour case.  They show that the bulk
of your time is being spent in low level (and probably optimized) code.
You may not be hitting the IdDict scaling wall in the 30 second test.
To make the 30 second test faster, I would figure out ways of reducing
the number of calls to the LargeInteger comparison.  To make the 5 hour
test faster, I'd profile it (or if that doesn't work, try profiling some
smaller piece of the 5 hour test...like one removal and at:put: 30
minutes into the operation).

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Chris Muller
> Sent: Tuesday, August 06, 2002 12:43 AM
> To: Squeak List
> Subject: Re: [Magma] performance (was: test result)
> 
> 
> The other issue to contend with looks like the 
> LargeInteger>>= comparisons.
> 
> Based on my current oid map, this looks like its going to be 
> something that could use improvement:
> 
> 0 to: 16r0000FFFFFFFFFFFF
> 	Integers from -140737488355328 to: 140737488355327
> 
> 16r0001000000000000 to: 16rFFFE999999999999
> 	Oids for user objects
> 
> 16rFFFF000000000000 to: (16rFFFF000000000000 + 65535)
> 	DBCS character set
> 
> 16rFFFF000000000000 + 65536
> 	nil
> 
> 16rFFFF000000000000 + 65537
> 	true
> 
> 16rFFFF000000000000 + 65538
> 	false
> 
> 16rFFFF000000000000 + 65539
> 	MaStorageForClass class ("metaclass")
> 
> 16rFFFF000000000000 + 65541
> 	special-value indicating an unused slot in a MaHashIndex
> 
> 16rFFFF000000000000 + 65542 to: 16rFFFF000000000000 + 65999
> 	future use?
> 
> 16rFFFF000000000000 + 66000 to: 16rFFFFFFFFFFFFFFFF
> 	new objects
> 
> I actually reserved the first 48-bits for "small" Integers.  
> I could down this to 32.  And since the small-Integer oids 
> are never stored in any dictionary, I could also actually 
> keep the LargePositiveInteger>>= primitive going by reducing 
> the oids for user objects by 32-bits.  This introduces an 
> LargeInteger addition/subtraction cost because they'd have to 
> be stored +32-bits in the file so they wouldn't be mistaken 
> for Integers, but at least it wouldn't be in scanFor:.
> 
> The advantage to this is Magma stays 100% Smalltalk.
> 
> The other option would be to learn Slang and plug-ins and try 
> to write an upgraded plug-in based on the existing primitive. 
>  I like this option because:
> 
>   - I'd be one step closer to a 64-bit Squeak
>   - motivated to learn Slang and plug-ins practicing 
> lower-level programming
>   - keeps the Magma code simpler, since it wouldn't have to 
> do the subtract/add
> 
> Not being familiar with this though, I have no idea what the 
> feasibility of it is.  Would it be as simple as copying the 
> code and tweaking it?
> 
> Looks like its time to dig out my blue Squeak book, I also 
> value your feedback.
> 
> Thanks,
>   Chris
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better http://health.yahoo.com
> 
>