FLSerialization>>analysisStep too slow?
My package TkIDE <http://smalltalkhub.com/#!/~tgkuo/TkIDE> relied on object database, sandstone, to store the objects. After upgrade to 6.1 on macOS, the save process became very slow. Following the debugging process, I found the bottle neck is at this method, FLSerialization>>analysisStep. I'm just a hobbyst, not acquainted with the system core and basis packages, I cann't figure out what the cause, just guessing maybe my object is too complicated to be serialized or the FLserialization really gets something wrong. Best reguards. Eno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Tue, Dec 12, 2017 at 11:47 AM, Eno <tgkuo1@gmail.com> wrote:
My package TkIDE <http://smalltalkhub.com/#!/~tgkuo/TkIDE> relied on object database, sandstone, to store the objects.
After upgrade to 6.1 on macOS, the save process became very slow.
Following the debugging process, I found the bottle neck is at this method, FLSerialization>>analysisStep.
Hi Eno, Well, its nothing strange analysisStep taking most of the time. That's usually the case as its the hardest part during serialization. What you should try is get deeper inside the analysisStep to see where the time is taken. Maybe you can realize a class or a cluster that's taking most of the time. You can also analyze this way: FileStream forceNewFileNamed: 'debug.fuel' do: [:aFile | FLSerializer newDefault setDebug; serialize: myDatabaseObject on: aFile binary]. FLDebugSerialization last log inspect. That will get you a log of all objects to be serialized and maybe you can see which cluster is getting too big. Hope this helps.
I'm just a hobbyst, not acquainted with the system core and basis packages, I cann't figure out what the cause, just guessing maybe my object is too complicated to be serialized or the FLserialization really gets something wrong.
Best reguards.
Eno
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
-- Mariano http://marianopeck.wordpress.com
Thanks Mariano. There is no such method: FLSerializer>>setDebug and FLDebugSerialization class in my 6.1 image. Anyway, my object has an instance variable that save the serialized glamour browser. I deleted that variable, and the saving process became quicker than before. Best regards, eno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Am 13.12.17 um 12:06 schrieb Eno:
Thanks Mariano.
There is no such method: FLSerializer>>setDebug and FLDebugSerialization class in my 6.1 image.
Debugging support needs to be loaded extra with "FuelDebug", like this: (ConfigurationOfFuel project stableVersion) load: #(default FuelDebug). Cheers, Andreas -- Andreas Brodbeck www.mindclue.ch
Hi eno can you tell us what is TkIDE? Because most of us are hobbysts .... the truth is in the eye of the beholder :) Stef On Tue, Dec 12, 2017 at 3:47 PM, Eno <tgkuo1@gmail.com> wrote:
My package TkIDE <http://smalltalkhub.com/#!/~tgkuo/TkIDE> relied on object database, sandstone, to store the objects.
After upgrade to 6.1 on macOS, the save process became very slow.
Following the debugging process, I found the bottle neck is at this method, FLSerialization>>analysisStep.
I'm just a hobbyst, not acquainted with the system core and basis packages, I cann't figure out what the cause, just guessing maybe my object is too complicated to be serialized or the FLserialization really gets something wrong.
Best reguards.
Eno
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Do you want that I help you defining a configuration for your project? Stef On Sat, Dec 16, 2017 at 9:10 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi eno
can you tell us what is TkIDE? Because most of us are hobbysts .... the truth is in the eye of the beholder :)
Stef
On Tue, Dec 12, 2017 at 3:47 PM, Eno <tgkuo1@gmail.com> wrote:
My package TkIDE <http://smalltalkhub.com/#!/~tgkuo/TkIDE> relied on object database, sandstone, to store the objects.
After upgrade to 6.1 on macOS, the save process became very slow.
Following the debugging process, I found the bottle neck is at this method, FLSerialization>>analysisStep.
I'm just a hobbyst, not acquainted with the system core and basis packages, I cann't figure out what the cause, just guessing maybe my object is too complicated to be serialized or the FLserialization really gets something wrong.
Best reguards.
Eno
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Sure, it's a great news that the leader could give me a hand. I came from Dolphin, not acquainted with pharo configuration, though I knew a lot that it could automize the loading and update. It depended upon Magritte3, Sandstone, and my packages. The store directory need to be changed in other's new image, currently, I set it fixed inside the method, MacOSResolver>>store, WindowsResolver>>store. On new installed image while running up via wordmenu, a new db file need to be created from the tool icon. Thanks. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Did you read the chapter on Metacello in deep into Pharo? in essence you create a class where you express dependencies to other projects and packages. Have a look at the configuration of Soup for example Object subclass: #ConfigurationOfSoup instanceVariableNames: 'project' classVariableNames: 'LastVersionLoad' package: 'ConfigurationOfSoup' ConfigurationOfSoup >> baseline19: spec <version: '1.9-baseline'> spec for: #'common' do: [ spec blessing: #'baseline'. spec repository: 'http://www.smalltalkhub.com/mc/PharoExtras/Soup/main'. spec project: 'XMLParser' with: [ spec className: #ConfigurationOfXMLParser; versionString: #'stable'; repository: 'http://www.smalltalkhub.com/mc/PharoExtras/XMLParser/main' ]. spec package: 'Soup-Core' with: [ spec requires: #('XMLParser' ). ]; package: 'Soup-Zinc' with: [ spec requires: #('Soup-Core' ). ]; package: 'Soup-XPath' with: [ spec requires: #('Soup-Core' ). ]; package: 'Soup-Help' with: [ spec requires: #('Soup-Core' ). ]; package: 'Soup-Tests-Core' with: [ spec requires: #('Soup-Core' ). ]; package: #'Soup-Tools' with: [ spec requires: #('Soup-Core' 'Soup-Zinc' 'Soup-XPath' 'Soup-Help' ). ]. ]. On Sun, Dec 17, 2017 at 6:53 AM, Eno <tgkuo1@gmail.com> wrote:
Sure, it's a great news that the leader could give me a hand.
I came from Dolphin, not acquainted with pharo configuration, though I knew a lot that it could automize the loading and update.
It depended upon Magritte3, Sandstone, and my packages.
The store directory need to be changed in other's new image, currently, I set it fixed inside the method, MacOSResolver>>store, WindowsResolver>>store.
On new installed image while running up via wordmenu, a new db file need to be created from the tool icon.
Thanks.
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Well, it is just my intent to place related playgrounds, doc, help, and classes/methods, mophic, tool browser etc into domain object dbs of topics/playgrounds trees while exploring the image and studing/writing packages. It's just a convenient help and an working enviornment I made specifically by my interest, not meant to replace the current IDE, using the tricks that the morphic browser would somehow integrate inside to glamour browser. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Sun, Dec 17, 2017 at 6:47 AM, Eno <tgkuo1@gmail.com> wrote:
Well, it is just my intent to place related playgrounds, doc, help, and classes/methods, mophic, tool browser etc into domain object dbs of topics/playgrounds trees while exploring the image and studing/writing packages.
can you explain how it is working (not the implementation) but the idea. Because you have living objects so why putting them in a dbs?
It's just a convenient help and an working enviornment I made specifically by my interest, not meant to replace the current IDE,
Sure
using the tricks that the morphic browser would somehow integrate inside to glamour browser.
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
participants (4)
-
Andreas Brodbeck -
Eno -
Mariano Martinez Peck -
Stephane Ducasse