MUHRTH@tubvm.cs.tu-berlin.de (Thomas Muhr) (08/16/90)
We just found our limits !-) If what we found is true, there is really a severe limitation of ST V for large applications: well known from the manual is the fact, that instances of class Symbol are excluded from garbage collection and that - from time to time - you have to manually recollect space by issuing Symbol purgeUnusedSymbols. But nowhere have I found a note about the upper limit for Symbols: In ours it is 5157, despite enough memory left for objects (1.5 MB unusedMemory). We have to redesign the system to never using any "asSymbol" or the like for Strings. The number of Symbols includes every classname and selector in the system, so that you have to be careful of how many methods you create, which contrasts the philosophy of OOP significantly. Our only hope is that some "goodie" (or baddy ?) has modified the complicated management of objects in an unpleasant way. Has anybody else experienced this barrier? Thanks in advance - Thomas PS.: Maybe it just got to late today.......
klimas@astro.pc.ab.com (08/17/90)
In article <90228.171958MUHRTH@DB0TUI11.BITNET>, MUHRTH@tubvm.cs.tu-berlin.de (Thomas Muhr) writes: > We just found our limits !-) What you mean "our limits"!? > If what we found is true, there is really a severe limitation of ST V > for large applications: well known from the manual is the fact, that > instances of class Symbol are excluded from garbage collection and that - > from time to time - you have to manually recollect space by issuing > Symbol purgeUnusedSymbols. The Symbols dictionary being a global variable is always going to hang around the system. That's the way it was designed to work. > But nowhere have I found a note about the upper limit for Symbols: In ours > it is 5157, despite enough memory left for objects (1.5 MB unusedMemory). Try reading Appendix 3:Pointer Table on page 467 of the manual. There is a discussion of parameters that can be adjusted to modify those limits. > We have to redesign the system to never using any "asSymbol" or the like > for Strings. Hmmmmm? I wonder about this??! > The number of Symbols includes every classname and selector in > the system, so that you have to be careful of how many methods you create, > which contrasts the philosophy of OOP significantly. Normally one can create quite a bit of code without worrying about it. If it does become a problem, then purge the table. I have used /V quite a bit and have rarely bumped into this. If one uses a code management system (such as the Carleton App Manager) to periodically rebuild the system from a virgin image then it is even less likely. > Our only hope is that some "goodie" (or baddy ?) has modified the complicated > management of objects in an unpleasant way. If one is building a big application then you should use /V286 or /V-PM which raise the limit to some level that we have never encountered problems with.