July 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] WorkingSession log

by Denis Kudriashov

> > 6ms startup:true a ClassSessionHandler(ExternalObject) Most time here is taken by ExternalAddress startUp logic: ExternalAddress>>startUp: resuming ... instances := self allInstances. wordSize ~= Smalltalk wordSize ifTrue: "Implement nulling by becomming all existing instances to new (and hence null) pointers of the right size." [wordSize := Smalltalk wordSize. instances elementsForwardIdentityTo: (instances collect: [:ea| self basicNew: wordSize])] ifFalse: [instances do: [:addr| addr beNull]]] It scans all instances which is very expensive. And I thing it can lead to much more time in bigger images. Maybe we can perform this cleanup at "prepare for production" script and add special flag in image that all externals are already clean. 2017-07-27 14:49 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi, > > I instrumented WorkingSession with a log collection that holds timing info > for each #startUp: executed. In a clean Pharo 6 image, 62 were run. Most of > them resulted in a 0ms execution time (#millisecondsToRun: i.e. they were > faster than 1ms). Here is the list of the non zero ones: > > 1ms startup:true a ClassSessionHandler(ProcessorScheduler) > 1ms startup:true a ClassSessionHandler(OSPlatform) > 6ms startup:true a ClassSessionHandler(ExternalObject) > 1ms startup:true a ClassSessionHandler(DiskStore) > 5ms startup:true a ClassSessionHandler(SmalltalkImage) > 9ms startup:true a ClassSessionHandler(DisplayScreen) > 1ms startup:true a ClassSessionHandler(Cursor) > 41ms startup:true a ClassSessionHandler(FT2Handle) > 238ms startup:true a ClassSessionHandler(FreeTypeSettings) > 1ms startup:true a ClassSessionHandler(WorldMorph) > 14ms startup:true a ClassSessionHandler(OmSessionStore) > > For a total of 318ms > > I think being able to inspect the WorkingSession and see this list > (ordered, with timing info) would be generally useful (and low cost). Even > headless, we could access the list using eval. > > Sven > > PS: The code of SessionManager/WorkingSession was very readable, well done > Christophe ! > > > > >

July 28, 2017

Re: [Pharo-dev] WorkingSession log

by Sven Van Caekenberghe

> On 28 Jul 2017, at 09:56, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Hi Sven, > >> Le 27 juil. 2017 Ã 14:49, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : >> >> Hi, >> >> I instrumented WorkingSession with a log collection that holds timing info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. they were faster than 1ms). Here is the list of the non zero ones: >> >> 1ms startup:true a ClassSessionHandler(ProcessorScheduler) >> 1ms startup:true a ClassSessionHandler(OSPlatform) >> 6ms startup:true a ClassSessionHandler(ExternalObject) >> 1ms startup:true a ClassSessionHandler(DiskStore) >> 5ms startup:true a ClassSessionHandler(SmalltalkImage) >> 9ms startup:true a ClassSessionHandler(DisplayScreen) >> 1ms startup:true a ClassSessionHandler(Cursor) >> 41ms startup:true a ClassSessionHandler(FT2Handle) >> 238ms startup:true a ClassSessionHandler(FreeTypeSettings) >> 1ms startup:true a ClassSessionHandler(WorldMorph) >> 14ms startup:true a ClassSessionHandler(OmSessionStore) >> >> For a total of 318ms >> >> I think being able to inspect the WorkingSession and see this list (ordered, with timing info) would be generally useful (and low cost). Even headless, we could access the list using eval. > > Yes, it is a nice feature. I basically did something similar to what Phil/Clement seem to have done: - added a local instance variable #log to WorkingSession holding an OrderedCollection - instrument #runStartup: and #executeDeferredStartupActions: like this runStartup: isImageStarting self runList: manager startupList do: [ :each | | ms | ms := Time millisecondsToRun: [ each startup: isImageStarting ]. log add: { ms. #startup:. isImageStarting. each } ]. self executeDeferredStartupActions: isImageStarting but if we do this for real, we better use a real object (like a log event, like SessionActionExecuted) > Do you have the same thing for #shutdown: ? I considered that, but if the session shuts down, it will disappear, hence the log will be lost, no ? Unless we also write it (optionally) to a file. >> Sven >> >> PS: The code of SessionManager/WorkingSession was very readable, well done Christophe ! > > Thanks but then you should also thanks Guille and Pablo as it was a joint work ;) Thank you Guille and Pablo !!

July 28, 2017

Re: [Pharo-dev] WorkingSession log

by Christophe Demarey

Hi Sven, > Le 27 juil. 2017 Ã 14:49, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > > Hi, > > I instrumented WorkingSession with a log collection that holds timing info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. they were faster than 1ms). Here is the list of the non zero ones: > > 1ms startup:true a ClassSessionHandler(ProcessorScheduler) > 1ms startup:true a ClassSessionHandler(OSPlatform) > 6ms startup:true a ClassSessionHandler(ExternalObject) > 1ms startup:true a ClassSessionHandler(DiskStore) > 5ms startup:true a ClassSessionHandler(SmalltalkImage) > 9ms startup:true a ClassSessionHandler(DisplayScreen) > 1ms startup:true a ClassSessionHandler(Cursor) > 41ms startup:true a ClassSessionHandler(FT2Handle) > 238ms startup:true a ClassSessionHandler(FreeTypeSettings) > 1ms startup:true a ClassSessionHandler(WorldMorph) > 14ms startup:true a ClassSessionHandler(OmSessionStore) > > For a total of 318ms > > I think being able to inspect the WorkingSession and see this list (ordered, with timing info) would be generally useful (and low cost). Even headless, we could access the list using eval. Yes, it is a nice feature. Do you have the same thing for #shutdown: ? > Sven > > PS: The code of SessionManager/WorkingSession was very readable, well done Christophe ! Thanks but then you should also thanks Guille and Pablo as it was a joint work ;)

July 28, 2017

Re: [Pharo-dev] WorkingSession log

by Denis Kudriashov

2017-07-28 7:39 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > I vaguely remember StrikeFonts being considered for removal once(??) > but this seems a good reason to not do that, and eliminate the FreeType > stuff for server-side deployment. > > There was experiment to cache FreeType font in image like StrikeFonts do (Igor did it I guess). It allows to not update anything on startup. > cheers -ben > > On Fri, Jul 28, 2017 at 3:14 AM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> This is really interesting. >> I would be interested to see why ClassSessionHandler(FreeTypeSettings) >> takes 2/3 of the computation. >> Without it we would be 100 ms. >> >> Stef >> >> On Thu, Jul 27, 2017 at 2:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > Hi, >> > >> > I instrumented WorkingSession with a log collection that holds timing >> info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. >> Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. >> they were faster than 1ms). Here is the list of the non zero ones: >> > >> > 1ms startup:true a ClassSessionHandler(ProcessorScheduler) >> > 1ms startup:true a ClassSessionHandler(OSPlatform) >> > 6ms startup:true a ClassSessionHandler(ExternalObject) >> > 1ms startup:true a ClassSessionHandler(DiskStore) >> > 5ms startup:true a ClassSessionHandler(SmalltalkImage) >> > 9ms startup:true a ClassSessionHandler(DisplayScreen) >> > 1ms startup:true a ClassSessionHandler(Cursor) >> > 41ms startup:true a ClassSessionHandler(FT2Handle) >> > 238ms startup:true a ClassSessionHandler(FreeTypeSettings) >> > 1ms startup:true a ClassSessionHandler(WorldMorph) >> > 14ms startup:true a ClassSessionHandler(OmSessionStore) >> > >> > For a total of 318ms >> > >> > I think being able to inspect the WorkingSession and see this list >> (ordered, with timing info) would be generally useful (and low cost). Even >> headless, we could access the list using eval. >> > >> > Sven >> > >> > PS: The code of SessionManager/WorkingSession was very readable, well >> done Christophe ! >> > >> > >> > >> > >> >> >

July 28, 2017

Re: [Pharo-dev] iceberg / libgit behind proxy

by Stephane Ducasse

Nicolai here are my setup (done with pavel) for pharo 70 active dev. There are two phases: - once done for all (cloning the repo) - once for each image I download I hope it helps (bt not for the proxy) Stef On Fri, Jul 28, 2017 at 8:02 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I did not try behind a proxy. > > On Thu, Jul 27, 2017 at 10:28 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> Anyone got it working to use iceberg /libgit behind a proxy? >> >> I can access monticello repositories with the right proxy settings. >> But using iceberg shows an error about >> can not access github.org >> >>

July 28, 2017

Re: [Pharo-dev] iceberg / libgit behind proxy

by Stephane Ducasse

I did not try behind a proxy. On Thu, Jul 27, 2017 at 10:28 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Anyone got it working to use iceberg /libgit behind a proxy? > > I can access monticello repositories with the right proxy settings. > But using iceberg shows an error about > can not access github.org > >

July 28, 2017

Re: [Pharo-dev] WorkingSession log

by Stephane Ducasse

Remove does not mean that we cannot reload. The font logic is a bit messy. So one of these days we will have to do a pass there. On Fri, Jul 28, 2017 at 7:39 AM, Ben Coman <btc(a)openinworld.com> wrote: > I vaguely remember StrikeFonts being considered for removal once(??) > but this seems a good reason to not do that, and eliminate the FreeType > stuff for server-side deployment. > > cheers -ben > > On Fri, Jul 28, 2017 at 3:14 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> This is really interesting. >> I would be interested to see why ClassSessionHandler(FreeTypeSettings) >> takes 2/3 of the computation. >> Without it we would be 100 ms. >> >> Stef >> >> On Thu, Jul 27, 2017 at 2:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > Hi, >> > >> > I instrumented WorkingSession with a log collection that holds timing >> > info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. >> > Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. they >> > were faster than 1ms). Here is the list of the non zero ones: >> > >> > 1ms startup:true a ClassSessionHandler(ProcessorScheduler) >> > 1ms startup:true a ClassSessionHandler(OSPlatform) >> > 6ms startup:true a ClassSessionHandler(ExternalObject) >> > 1ms startup:true a ClassSessionHandler(DiskStore) >> > 5ms startup:true a ClassSessionHandler(SmalltalkImage) >> > 9ms startup:true a ClassSessionHandler(DisplayScreen) >> > 1ms startup:true a ClassSessionHandler(Cursor) >> > 41ms startup:true a ClassSessionHandler(FT2Handle) >> > 238ms startup:true a ClassSessionHandler(FreeTypeSettings) >> > 1ms startup:true a ClassSessionHandler(WorldMorph) >> > 14ms startup:true a ClassSessionHandler(OmSessionStore) >> > >> > For a total of 318ms >> > >> > I think being able to inspect the WorkingSession and see this list >> > (ordered, with timing info) would be generally useful (and low cost). Even >> > headless, we could access the list using eval. >> > >> > Sven >> > >> > PS: The code of SessionManager/WorkingSession was very readable, well >> > done Christophe ! >> > >> > >> > >> > >> >

July 28, 2017

Re: [Pharo-dev] WorkingSession log

by Ben Coman

I vaguely remember StrikeFonts being considered for removal once(??) but this seems a good reason to not do that, and eliminate the FreeType stuff for server-side deployment. cheers -ben On Fri, Jul 28, 2017 at 3:14 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > This is really interesting. > I would be interested to see why ClassSessionHandler(FreeTypeSettings) > takes 2/3 of the computation. > Without it we would be 100 ms. > > Stef > > On Thu, Jul 27, 2017 at 2:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Hi, > > > > I instrumented WorkingSession with a log collection that holds timing > info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. > Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. > they were faster than 1ms). Here is the list of the non zero ones: > > > > 1ms startup:true a ClassSessionHandler(ProcessorScheduler) > > 1ms startup:true a ClassSessionHandler(OSPlatform) > > 6ms startup:true a ClassSessionHandler(ExternalObject) > > 1ms startup:true a ClassSessionHandler(DiskStore) > > 5ms startup:true a ClassSessionHandler(SmalltalkImage) > > 9ms startup:true a ClassSessionHandler(DisplayScreen) > > 1ms startup:true a ClassSessionHandler(Cursor) > > 41ms startup:true a ClassSessionHandler(FT2Handle) > > 238ms startup:true a ClassSessionHandler(FreeTypeSettings) > > 1ms startup:true a ClassSessionHandler(WorldMorph) > > 14ms startup:true a ClassSessionHandler(OmSessionStore) > > > > For a total of 318ms > > > > I think being able to inspect the WorkingSession and see this list > (ordered, with timing info) would be generally useful (and low cost). Even > headless, we could access the list using eval. > > > > Sven > > > > PS: The code of SessionManager/WorkingSession was very readable, well > done Christophe ! > > > > > > > > > >

July 28, 2017

iceberg / libgit behind proxy

by Nicolai Hess

Anyone got it working to use iceberg /libgit behind a proxy? I can access monticello repositories with the right proxy settings. But using iceberg shows an error about can not access github.org

July 27, 2017

Re: [Pharo-dev] Improving formatting [was: Big claps for Epicea (small request!)]

by Stephane Ducasse

> Hi Denis, > you're right, for literal numbers it's been solved in Pharo at least since > 3.0, or maybe even 2.0 (by usage of RB AST I guess). > That's a major improvment over Squeak which is is certainly where I last > encountered the problem. > > Still, formatting does mess line breaking/indenting/commenting in literal > arrays. Yes I would love to have a better heuristics. Now we refactored the prettyprinter so it should be easier to play and enhance it.

July 27, 2017