December 2017 - Pharo-users

Re: [Pharo-users] Fuel serialize of 70MB takes forever on Linux vs. Mac

by Ben Coman

On 19 December 2017 at 00:35, Andreas Brodbeck <dassi(a)mindclue.ch> wrote: > Hi all! > > I have a performance problem with Fuel (latest stable) on a Pharo 6.1 > (32bit) on Ubuntu 16.04.3 LTS. The serialization and storage to disk of > 70MB of data takes more than 6 minutes! While the same task on an > equally powerful Mac takes only 1.5 minutes. > > My observation was, that on Linux it is very very slow while writing the > file. The first 30MB of the file are written very fast, but after that > the writing speed drops dramatically. > > On the same Linux server, but the application running on an old Pharo > 1.4, the serialization was always as fast as on the Mac. > > Attached you see an excerpt of the Pharo Time profiler output for the > serialization. The profiling tree looks the same on the Mac, just with > faster times. > > What could be the hidden speed eating secret on Linux for Pharo6.1? I > have absolutely no idea where to search! Memory? Streams? File writing > support? Something inside Fuel? > On 19 December 2017 at 03:45, Henrik-Nergaard <draagren(a)outlook.com> wrote: > Hi Andreas, > > It looks like you may have problems with hash collisions > FLLargeIdentityDictionary. > What are the tally sizes of the FLLargeIdentityDicitonary used when you > serialize? (If these have a tally larger than ~ 75% of the available size > (4096 items), then there may well be some performance loss). > > You could check if file writing is the problem by measuring the time it > takes to only serialize in memory. > You can try to use: "FLSerializer serializeToByteArray: " and see if it > gives better performance? > side comment: I wonder what could be the performance of hooking #serializeToByteArray: up directly to mmap ? * http://forum.world.st/Pharo-Shared-Memory-with-C-executable-td4921928.html * http://forum.world.st/ANN-CPPBridge-One-Ring-to-rule-them-ALL-td4922275.htm… cheers -ben

Dec. 18, 2017

Re: [Pharo-users] Athens error

by Hilaire

Sadly building the image with a light cleaning, does not grant me access to the morph menu of the faulty canvas. Still same error as mentionned in previous screenshot. The upper moprh menu can be access, but there is stack trace entry in its menu (see screesshot). In the following day will try with another image... Le 17/12/2017 Ã 20:55, Hilaire a Ã©critÂ : > May be something else is wrong in the image, in the next days I will > try to build differently the image application -- Dr. Geo http://drgeo.eu

Dec. 18, 2017

Re: [Pharo-users] unsolicited package-cache use

by Hilaire

If understood correctly, when using a tonel file repository to build up an image, Pharo seems instead to take the sources from some package-cache, which is out of sync, because the tonel file repo was updated from another image, with a different cache. I guess I can trick the file system but it is for the least very annoying, for the worst unreliable. Le 10/12/2017 Ã 18:16, Hilaire a Ã©critÂ : > I am using tonel format to install from and save to a local repository. > > How to prevent Monticello/Configuration/Metacello to save packages to > the image package-cache dir? > > Even when installing from a configuration with repo on tonel file > format, packages get created in the image package-cache directory. > > I have read there and there, Pharo gets confused and uses wrongly the > package-cache versions and not the local repo. -- Dr. Geo http://drgeo.eu

Dec. 18, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by Sean P. DeNigris

Sean P. DeNigris wrote > I got: MetacelloProjectSpecLoadError:â¦ I then removed the FuelPreview group and got a missing NativeBoost dependecy (NBExternalHandle)! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 18, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by Sean P. DeNigris

Andreas Brodbeck-3 wrote > --- Install Fuel version 1.9.4 for debugging: > (ConfigurationOfFuel project version: '1.9.4') > load: #(default FuelDebug FuelPreview). Hmmm. In Pharo #60510, I got: MetacelloProjectSpecLoadError: No version found for '1.61' of ConfigurationOfRoassal because: Version '1.61' is not defined in ConfigurationOfRoassal. Possible versions include: #(#bleedingEdge #development #stable '0.5-baseline' '0.6-baseline' '0.7-baseline' '1.6-snapshot' '1.400' '1.401' '1.402' '1.403' '1.404' '1.405' '1.406' '1.407' '1.408' '1.409' '1.410' '1.411' '1.412' '1.413' '1.414' '1.415' '1.416' '1.417' '1.418' '1.419' '1.420' '1.421' '1.422' '1.423' '1.424' '1.425' '1.426' '1.427' '1.428-snapshot' '1.429' '1.430') ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 18, 2017

Re: [Pharo-users] Fuel serialize of 70MB takes forever on Linux vs. Mac

by Henrik-Nergaard

Hi Andreas, It looks like you may have problems with hash collisions FLLargeIdentityDictionary. What are the tally sizes of the FLLargeIdentityDicitonary used when you serialize? (If these have a tally larger than ~ 75% of the available size (4096 items), then there may well be some performance loss). You could check if file writing is the problem by measuring the time it takes to only serialize in memory. You can try to use: "FLSerializer serializeToByteArray: " and see if it gives petter performance? Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 18, 2017

Fuel serialize of 70MB takes forever on Linux vs. Mac

by Andreas Brodbeck

Hi all! I have a performance problem with Fuel (latest stable) on a Pharo 6.1 (32bit) on Ubuntu 16.04.3 LTS. The serialization and storage to disk of 70MB of data takes more than 6 minutes! While the same task on an equally powerful Mac takes only 1.5 minutes. My observation was, that on Linux it is very very slow while writing the file. The first 30MB of the file are written very fast, but after that the writing speed drops dramatically. On the same Linux server, but the application running on an old Pharo 1.4, the serialization was always as fast as on the Mac. Attached you see an excerpt of the Pharo Time profiler output for the serialization. The profiling tree looks the same on the Mac, just with faster times. What could be the hidden speed eating secret on Linux for Pharo6.1? I have absolutely no idea where to search! Memory? Streams? File writing support? Something inside Fuel? Thanks for any help! Cheers, Andreas -- Andreas Brodbeck www.mindclue.ch

Dec. 18, 2017

Re: [Pharo-users] Pharo Launcher name

by Christophe Demarey

I agree. We should rename it PharoLauncher. > Le 18 dÃ©c. 2017 Ã 03:05, Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > > Mariano Martinez Peck wrote >> I also find having it called Pharo quite disturbing. PharoLauncher should >> be much betterâ¦ > > +1. IIRC the original idea was that the launcher would be *the* way new > users would experience Pharo, so it should simply be called "Pharo", but the > term already has a meaning to many people, so IMHO it created more confusion > than anything. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Dec. 18, 2017

Pharo Glorp platform decimal to ScaledDecimal mapping

by Alistair Grant

Hi Everyone, I've added mapping from platform decimal to ScaledDecimal for Pharo / Glorp. It's currently on the development branch and I'll move it to the master branch in a few days, assuming I don't hear of any issues. Pharo Glorp repository: https://github.com/pharo-rdbms/glorp Cheers, Alistair

Dec. 18, 2017

Re: [Pharo-users] Pharo Launcher name

by Sean P. DeNigris

Mariano Martinez Peck wrote > I also find having it called Pharo quite disturbing. PharoLauncher should > be much betterâ¦ +1. IIRC the original idea was that the launcher would be *the* way new users would experience Pharo, so it should simply be called "Pharo", but the term already has a meaning to many people, so IMHO it created more confusion than anything. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 18, 2017