"Try this one wierd trick"
Object subclass: #Foo
instanceVariableNames: ''
classVariableNames: 'PageId PageTitle Lua'
poolDictionaries: ''
category: 'Foo-Bar'.
"Open a browser and highlight the Foo-Bar category. Then.."
1 to:3000 do: [:each | | newclassname|
newclassname := ('FooBar', each asString) asSymbol.
Foo subclass: newclassname
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Foo-Bar']
"Your system should slow to a crawl.
Be patient and click off of the 'Foo-Bar' category and the system should free up.
Now open a HierarchyBrowser on Foo
Things will continue to work smoothly.
Conclusion? Something funky with Browser.
"
Foo allSubclasses do: [:each |
Smalltalk removeClassNamed: (each name)
]
Smalltalk removeClassNamed: #Foo
ClassOrganizer removeCategory:'Foo-Bar'
Motivation.
I am on a "import that as a class" kick for SeasideDock and the WikitextParser I am working on.
I am comfortable working with these classes as I have learned to NEVER open certain categories and use the HierarchyBrowser when I need to scan the classes therein.
Thought somebody might be intrigued with the "Why" of this on purely technical grounds. I am not that guy (:
cheers.
t
Hmm... HierarchyBrowser has a cache in #classList. Browser has no such cache. Browser >> #hierarchicalClassList is slow.
Also, class compilation is so slow because of SmalltalkImage >> #logChange:.
84.7% {13730ms} SmalltalkImage>>logChange: 84.6% {13718ms} SmalltalkImage>>forceChangesToDisk 79.6% {12899ms} MultiByteFileStream(StandardFileStream)>>close |79.6% {12899ms} MultiByteFileStream(StandardFileStream)>>unregister 4.9% {798ms} SecurityManager class>>default
Best, Marcel Am 22.08.2019 18:45:43 schrieb gettimothy via Squeak-dev squeak-dev@lists.squeakfoundation.org: "Try this one wierd trick"
Object subclass: #Foo
instanceVariableNames: ''
classVariableNames: 'PageId PageTitle Lua'
poolDictionaries: ''
category: 'Foo-Bar'.
"Open a browser and highlight the Foo-Bar category. Then.."
1 to:3000 do: [:each | | newclassname|
newclassname := ('FooBar', each asString) asSymbol.
Foo subclass: newclassname
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Foo-Bar']
"Your system should slow to a crawl.
Be patient and click off of the 'Foo-Bar' category and the system should free up.
Now open a HierarchyBrowser on Foo
Things will continue to work smoothly.
Conclusion? Something funky with Browser.
"
Foo allSubclasses do: [:each |
Smalltalk removeClassNamed: (each name)
]
Smalltalk removeClassNamed: #Foo
ClassOrganizer removeCategory:'Foo-Bar'
Motivation.
I am on a "import that as a class" kick for SeasideDock and the WikitextParser I am working on.
I am comfortable working with these classes as I have learned to NEVER open certain categories and use the HierarchyBrowser when I need to scan the classes therein.
Thought somebody might be intrigued with the "Why" of this on purely technical grounds. I am not that guy (:
cheers.
t
On Fri, 23 Aug 2019, Marcel Taeumel wrote:
Hmm... HierarchyBrowser has a cache in #classList. Browser has no such cache. Browser >> #hierarchicalClassList is slow. Also, class compilation is so slow because of SmalltalkImage >> #logChange:.
I'm not sure that's true. It seems to be more like a mismeasurement by the profiler. The following takes ~200ms on my machine (it should remove the spam from the changes file, but use at your own risk):
| startPosition | startPosition := (SourceFiles at: 2) size. [ 10000 timesRepeat: [ Smalltalk logChange: 'test' ] ] timeProfile. (SourceFiles at: 2) truncate: startPosition.
Also, #forceChangesToDisk's trick to force write-to-disk by closing and reopening the file won't work in modern OSes. They'll realize that you're reopening a file already in your process's cache, and will just provide you with the cached file without forcing the contents to be written to disk. We have #sync to actually force write-to-disk, but using that in #forceChangesToDisk will make the above snippet 250x slower (or more if your storage device is not that fast).
Levente
84.7% {13730ms} SmalltalkImage>>logChange: 84.6% {13718ms} SmalltalkImage>>forceChangesToDisk 79.6% {12899ms} MultiByteFileStream(StandardFileStream)>>close |79.6% {12899ms} MultiByteFileStream(StandardFileStream)>>unregister 4.9% {798ms} SecurityManager class>>default
Best, Marcel
Am 22.08.2019 18:45:43 schrieb gettimothy via Squeak-dev <squeak-dev@lists.squeakfoundation.org>: "Try this one wierd trick"
Object subclass: #Foo instanceVariableNames: '' classVariableNames: 'PageId PageTitle Lua' poolDictionaries: '' category: 'Foo-Bar'.
"Open a browser and highlight the Foo-Bar category. Then.."
1 to:3000 do: [:each | | newclassname| newclassname := ('FooBar', each asString) asSymbol. Foo subclass: newclassname instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Foo-Bar']
"Your system should slow to a crawl. Be patient and click off of the 'Foo-Bar' category and the system should free up.
Now open a HierarchyBrowser on Foo Things will continue to work smoothly.
Conclusion? Something funky with Browser. "
Foo allSubclasses do: [:each | Smalltalk removeClassNamed: (each name) ] Smalltalk removeClassNamed: #Foo ClassOrganizer removeCategory:'Foo-Bar'
Motivation.
I am on a "import that as a class" kick for SeasideDock and the WikitextParser I am working on.
I am comfortable working with these classes as I have learned to NEVER open certain categories and use the HierarchyBrowser when I need to scan the classes therein.
Thought somebody might be intrigued with the "Why" of this on purely technical grounds. I am not that guy (:
cheers.
t
On Fri, Aug 23, 2019 at 6:23 AM Levente Uzonyi leves@caesar.elte.hu wrote:
On Fri, 23 Aug 2019, Marcel Taeumel wrote:
Hmm... HierarchyBrowser has a cache in #classList. Browser has no such
cache. Browser >> #hierarchicalClassList is slow.
Also, class compilation is so slow because of SmalltalkImage >>
#logChange:.
I'm not sure that's true. It seems to be more like a mismeasurement by the profiler. The following takes ~200ms on my machine (it should remove the spam from the changes file, but use at your own risk):
| startPosition | startPosition := (SourceFiles at: 2) size. [ 10000 timesRepeat: [ Smalltalk logChange: 'test' ] ] timeProfile. (SourceFiles at: 2) truncate: startPosition.
Also, #forceChangesToDisk's trick to force write-to-disk by closing and reopening the file won't work in modern OSes. They'll realize that you're reopening a file already in your process's cache, and will just provide you with the cached file without forcing the contents to be written to disk. We have #sync to actually force write-to-disk, but using that in #forceChangesToDisk will make the above snippet 250x slower (or more if your storage device is not that fast).
Magma handles a similar issue in its need to #sync by doing it no more than every 5 seconds.
- Chris
squeak-dev@lists.squeakfoundation.org