It has been a long time ago, when I played with this wrapper. I talked to another (VA-)Smalltalker and he told me about the long time to do very, large transactions using SQLite.
I tested very large transactions with Dybase and found a non-linear behaviour in saving time with a jump at 30000 instances. Doing some benchmarks showed, that most of the time has been used in the handling of IdentitySet instance holding the changed instances, which should be stored into the database at commit time.
I remembered discussions about 16-bit hash values and there were several users in the past who wanted to have 32-bit hash values for objects. The problem is, that when having 16-bit hash values and you have many more objects to handle, the behaviour-speed of these IdentitySets (or other structures) are getting worse very fast.
In VASmalltalk you get (16-bit-)hash values by sending #basicHash to an instance. Each objects gets another hash values, even a equality (=) compare is true. If an identity (==) compare is true, then the objects have the same hash values. The behaviour is in contradiction to the method comment, but is actually the behaviour I would expect.
To get 32-bit hash values you might use the method #abtHash32, but this method behaves totally different than #basicHash. Objects with equality-compare have the same 32-bit values and each change to an instance variable gives a different 32-bit hash value …. but actually it behaves like the method comment suggest.
I wrote a primitive to produce a 32-bit hash value – hope, that it works :-)))). Then I create a new 32-bit aware IdentitySet class and add it to the MSKSystemExtension map.
With that primitive and the new IdentitySet class the commit-time of very large transactions went down to 1/10 of the original time.
Now I should only know, if that 32-bit hash method is really doing, what it is supposed to do ….🙂