[Magma] performance (was: test result)
afunkyobject at yahoo.com
Tue Aug 6 04:43:24 UTC 2002
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
16rFFFF000000000000 + 65537
16rFFFF000000000000 + 65538
16rFFFF000000000000 + 65539
MaStorageForClass class ("metaclass")
16rFFFF000000000000 + 65541
special-value indicating an unused slot in a MaHashIndex
16rFFFF000000000000 + 65542 to: 16rFFFF000000000000 + 65999
16rFFFF000000000000 + 66000 to: 16rFFFFFFFFFFFFFFFF
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
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.
Do You Yahoo!?
Yahoo! Health - Feel better, live better
More information about the Squeak-dev