search

squeak-smalltalk / squeak-object-memory

Issues and assets related to the Squeak object memory.
https://bugs.squeak.org
MIT License
11 stars 1 forks source link

Inspector can be slow for dictionaries #35

Open j4yk opened 2 years ago

j4yk commented 2 years ago

Try inspecting the DependentsFields class variable in Object. In an image with many such dependents (I have 17966 in the image in which I tried it). It will take a while to open the inspector, and once it is open will still make Squeak overall less responsive (maybe due to the polling updates of the inspector and thus taking the long time more often, in the UI process).

(~The inspectors for sequenceable collections cut short the amount of fields with an ellipsis item (...). The dictionary inspectors apparently do not do the same.~ EDIT: I just inspected another WeakIdentityKeyDictionary with 23081 elements and everything was fine there, and there was an ellipsis field.

~Would it make sense to also introduce the ellipsis for dictionaries? Or is there a better way to get a faster reaction from Squeak?~)

Can we protect the tools from slowness introduced by certain collection elements with reasonable effort?

Squeak version: ~21829~ 21848 Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-mt.3184] Win32 built on May 11 2022 07:53:00 Compiler: Clang 14.0.0 platform sources revision VM: 202205110711

j4yk commented 2 years ago

I edited the issue description to withdraw the wrong assumption that the size of the dictionary was the main driver for the slowness.

marceltaeumel commented 2 years ago

Hmm... there is currently no protection against, for example, a slow #printString response from an object. Well, we have a character limit, which I fixed recently to not make the Object Explorer too slow. I think that the Inspector does not send any messages to the object parts under inspection unless the user clicked on one. Hmm... in dictionaries, the key might be tricky if its #printString is slow. There, we might want to optimize more via #printStringLimitedTo:? An exception-based time out like in tests might be overkill here... and even introduce another kind of overhead... Hmm...

LinqLover commented 2 years ago

From my subjective experience, interrupting a slow inspector/explorer often brought me to #keysSortedSafely. Maybe one other speed-up could be to forego the sorting phase if the dictionary has a very large size.

marceltaeumel commented 2 years ago

Yes, it looks like both sorting and maybe print-string (if used in an object's #= or #hash) might be the issue for certain configurations of DependentsFields in Object:

grafik