"I first used image persistence but the image grow too large.." thanks for reminding, Norbert. Hi all, perhaps you'll find me an idiot, I don't care. (i know that I am: (class SelfReflection :o) ) Nevertheless, some brainstorming here. I've brought this up before, but it seems nobody is interested in this topic.. why? it's about image size. Currently, Pharo 1.3-13315 at my 4 Gigabyte Debian amd64 Linux machine reports memory 75,392,160 bytes old 61,370,144 bytes (81.4%) young 2,169,692 bytes (2.9000000000000004%) used 63,539,836 bytes (84.30000000000001%) free 11,852,324 bytes (15.700000000000001%) (nothing peculiar added, just the Seaside package and a few classes of my own. ) So, if i understand this well I have only 11,8 megabytes to play with? To begin with: why is only 75 megabyte available in Pharo (or Squeak as well) when there is 4 gigabyte physical memory available on my machine?? Anyway, IMHO this very limited storage violates the Smalltalk-all-in-one image ideal, because with this limited storage one cannot avoid the use of external data stores like databases (of course, exception: there always will be import an export of objects/data) External data storage is complex, unreliable and should be something of the past. I'd suggest: don't waste time with this. rather improve the Smalltalk internal data handling. I wish to have a very large image so e.q. I can have an entire company's administration (client and accounting data etc.) alive in it. I want to use Collections and descendants, not external databases. So, everything within the image. The beautiful (although opinions may vary) principle of a Smalltalk environment is Image Persistence, isn't it? IMHO this requires: - virtually unlimited image memory size. -no external databases like e.g. Mongo or DB2 whatever. -no persistent external storage at all. -You should see the (currently still) faster database performance as a challenge to improve the Collection and other related data handling classes -You would have to completely restructure the architecture. or just extend the address width: 64 bits? what about an image of virtually unlimited size > gigabytes so (for now, if it goes beyond the physical memory size (say 32 GB?) one could use a VM that works with virtual storage based VM Virtual storage was first in use successfully with IBM mainframes in the 1970s (and still is) ) on the other hand, I estimate holographic? physical memory going in Terabytes is about to be available in 5-10 years from now. blindingly fast, compared with today's standards. So, one has about 5 years to come up with such a system :o) if one does, Smalltalk is ahead of everything then.. Don't laugh. One didn't even dream of 4 gigabytes of memory during the Commodore 64 era. 1982-1994. In short: what would have to be changed to enable this? Some thoughts and speculations? Anyone for tennis? Thanks Ted -- Ted F.A. van Gaalen Danketsweiler 608 D-88263 Horgenzell Germany T: +49 750 491 48 38 M: +49 151 587 862 47