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
|
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 <[hidden email]>: > > "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 <[hidden email]> wrote: On Fri, 23 Aug 2019, Marcel Taeumel wrote: Magma handles a similar issue in its need to #sync by doing it no more than every 5 seconds. - Chris |
Free forum by Nabble | Edit this page |