Hi All, we are simulating a full block Pharo image derived from Pharo 6. On startup we see a very sad loss of cycles due to a very slow rebuild of the selector table in Symbol class. Why is this done at each startup? Here is the stack: 16r107154 M ByteString class(ProtoObject)>identityHash 16r786AE8: a(n) ByteString class 16r10716C M ByteString class(Object)>hash 16r786AE8: a(n) ByteString class 16r10718C M ByteSymbol(String)>hash 16rE6A5C8: a(n) ByteSymbol 16r1071B0 M WeakSet>scanForEmptySlotFor: 16r26B968: a(n) WeakSet 16r1071DC M WeakSet>noCheckNoGrowFillFrom: 16r26B968: a(n) WeakSet 16r1071FC M WeakSet>growTo: 16r26B968: a(n) WeakSet 16r10721C M WeakSet>grow 16r26B968: a(n) WeakSet 16r107234 M WeakSet(HashedCollection)>fullCheck 16r26B968: a(n) WeakSet 16r10724C M WeakSet(HashedCollection)>atNewIndex:put: 16r26B968: a(n) WeakSet 16r107274 M WeakSet>add: 16r26B968: a(n) WeakSet 16r107294 M [] in Symbol class>(nil) 16r1D319A8: a(n) Symbol class 16r1072B8 M Array(SequenceableCollection)>do: 16r3C17370: a(n) Array 16r1072E8 I CompiledMethod class(Behavior)>allInstancesDo: 16r164E260: a(n) CompiledMethod class 16r10730C I Symbol class>initSelectorTable 16r1D319A8: a(n) Symbol class 16r10732C I Symbol class>selectorTable 16r1D319A8: a(n) Symbol class 16r107350 I Symbol class>internSelector: 16r1D319A8: a(n) Symbol class 16r10737C I CompiledMethod>selector: 16r26AB58: a(n) CompiledMethod 16r1073A4 I IRMethod>generate: 16r25A030: a(n) IRMethod 16r1073CC I FFICalloutMethodBuilder>generateMethodFromSpec: 16r255580: a(n) FFICalloutMethodBuilder 16r1073F0 I FFICalloutMethodBuilder>generate 16r255580: a(n) FFICalloutMethodBuilder 16r1030C8 I FFICalloutMethodBuilder>build: 16r255580: a(n) FFICalloutMethodBuilder 16r1030F4 I FFICalloutAPI>function:module: 16r255568: a(n) FFICalloutAPI 16r10311C I UnixEnvironment(Object)>ffiCall:module: 16r3816180: a(n) UnixEnvironment 16r103144 I UnixEnvironment(OSEnvironment)>getEnv: 16r3816180: a(n) UnixEnvironment 16r103168 I UnixEnvironment(OSEnvironment)>at:ifAbsent: 16r3816180: a(n) UnixEnvironment 16r10318C M [] in MacOSResolver>(nil) 16r241170: a(n) MacOSResolver 16r1031A4 M FullBlockClosure(BlockClosure)>on:do: 16r2553F0: a(n) FullBlockClosure 16r1031D0 I MacOSResolver(PlatformResolver)>directoryFromEnvVariableNamed:or: 16r241170: a(n) MacOSResolver 16r1031F8 I MacOSResolver(PlatformResolver)>directoryFromEnvVariableNamed: 16r241170: a(n) MacOSResolver 16r10321C I MacOSResolver>home 16r241170: a(n) MacOSResolver 16r10323C I MacOSResolver>userLibrary 16r241170: a(n) MacOSResolver 16r103254 M MacOSResolver>userApplicationSupport 16r241170: a(n) MacOSResolver 16r10326C M MacOSResolver(FileSystemResolver)>resolve: 16r241170: a(n) MacOSResolver 16r103288 M SystemResolver(FileSystemResolver)>unknownOrigin: 16r240D30: a(n) SystemResolver 16r1032A4 M SystemResolver(FileSystemResolver)>resolve: 16r240D30: a(n) SystemResolver 16r1032C4 M InteractiveResolver>unknownOrigin: 16r240CF0: a(n) InteractiveResolver 16r1032E4 M [] in InteractiveResolver>(nil) 16r240CF0: a(n) InteractiveResolver 16r103300 M IdentityDictionary(Dictionary)>at:ifAbsent: 16r240D00: a(n) IdentityDictionary 16r103320 M InteractiveResolver>resolve: 16r240CF0: a(n) InteractiveResolver 16r10333C M FileLocator>resolve 16r255258: a(n) FileLocator 16r103354 M FileLocator(AbstractFileReference)>exists 16r255258: a(n) FileLocator 16r10337C M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener 16r103398 M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener 16r1033B0 M FullBlockClosure(BlockClosure)>on:do: 16r255190: a(n) FullBlockClosure 16r1033D0 M FullBlockClosure(BlockClosure)>ifError: 16r255190: a(n) FullBlockClosure 16r1033EC M PharoFilesOpener>ignoreIfFail: 16rE79FD8: a(n) PharoFilesOpener 16r102188 M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) PharoFilesOpener 16r1021AC M Array(SequenceableCollection)>do: 16r2495E8: a(n) Array 16r1021DC I PharoFilesOpener>openSources:forImage: 16rE79FD8: a(n) PharoFilesOpener 16r102204 I PharoFilesOpener>openSources 16rE79FD8: a(n) PharoFilesOpener 16r102228 I PharoFilesOpener>sourcesFileOrNil 16rE79FD8: a(n) PharoFilesOpener 16r10224C I SourceFileArray>ensureOpen 16r8AA128: a(n) SourceFileArray 16r10226C I SmalltalkImage>openSourceFiles 16rA58A28: a(n) SmalltalkImage 16r10228C I SmalltalkImage class>startUp: 16rFDA6A8: a(n) SmalltalkImage class 16r1022A8 M ClassSessionHandler>startup: 16r8B8978: a(n) ClassSessionHandler 16r1022C8 M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession 16r1022EC M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession 16r102304 M FullBlockClosure(BlockClosure)>on:do: 16r245640: a(n) FullBlockClosure 16r102328 M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession 16r10234C M Array(SequenceableCollection)>do: 16r1A47B8: a(n) Array 16r102370 I WorkingSession>runList:do: 16r1A45D0: a(n) WorkingSession 16r102398 I WorkingSession>runStartup: 16r1A45D0: a(n) WorkingSession 16r1023BC I WorkingSession>start: 16r1A45D0: a(n) WorkingSession 16r1023E8 I SessionManager>snapshot:andQuit: 16r17AA950: a(n) SessionManager You'll see that Symbol class>selectorTable calls Symbol class> initSelectorTable which then calls CompiledMethod class(Behavior)>allInstancesDo: to enumerate over all methods. This takes a significant amount of time, even on a fast machine. For example, on a 2.%GHz machine this takes about 70 milliseconds. That's a /lot/ of time to squander on startup. And it will grow the larger the image is. The selector table seems to be discarded on shut-down, which seems pointless. If one wants to recompute the table then before or after methods are added or removed seems like a better choice, not on every image startup. In around 2000 we were able to startup VisualWorks images in about 40 milliseconds on the hardware available at the time. I hope someone reconsiders this code and a avoids recomputing the selector table on each startup. _,,,^..^,,,_ best, Eliot