September 2016 - Pharo-users

Re: [Pharo-users] [ANN] Territorial Re-Licensing

by stepharo

You can be proud of you. I'm proud of you and I can tell you that I really understand you. I can tell you that once I was tempted to change the license of my new books because bad people could just take everything. (yes this is silly when you read but I thought about it and we even discussed it in the book mailing-list). And I changed my mind and continue to use the most liberal CC license. And I have sometimes the same doubts with Pharo code. Nothing prevents people to copy what we took ages to build. Now let us live along with that. Now what is important for our community is how we get money inside and that people can make a living. You can add yourself to the Pharo consultant list (sadly I do not think that it will get an impact but we should do it). Now what would be nice to know is what are the time you can do on other paid projects and what are the domains of expertise you have so that if we know companies they can be put in contact with you. Stef Le 8/9/16 Ã 06:00, HernÃ¡n Morales Durand a Ã©crit : > > I consider GNU AGPL v3 a fair license choice which protects somehow > authors. After some talks with friends today, I began to consider it > useless for a niche community like Smalltalk *and* solo projects. I > then read all your mails, many posts in other communities, and finally > asked for advices. Conclusion: The ideal license option for me was not > yet invented. > > Now about parasite behavior and easy living for freeloaders. > > - I doubt Smalltalkers are in position for doing anything valuable > against parasites. GPL scares a niche community. All of us having MIT > code published can be stealed and we have no legal options to defend > our work/authorship. That should be addressed one day. > > - However, I would like one day to read people releasing software > under whatever license they want and not to be pointed them. That's a > matter of freedom. I feel we are far away from there. > > - I hope we can talk about interesting Territorial features, what do > you need, what could be modeled better, etc. Licensing is boring, really. > > I re-licensed Territorial to MIT for the nice Pharo people, for the > nice Smalltalkers, people who helped me here in mailing lists, or > sending supportive private messages, and for cool users with nice > intentions. > > HernÃ¡n > > PS: Updated User Manual: http://bit.ly/2c4RrCJ > > >

Sept. 8, 2016

Small OS-... project addition

by Torsten Bergmann

Hi, now also the OSX project in the OS series [1] has support to - directly open a terminal - directly open a file browser (Finder) on the working directory right from the Pharo tools menu. See attached screenshot. Depending on your platform just load - OSOSX - OSWindows - OSLinuxUbuntu - OSLinuxCentOS from catalog. Bye T. [1] http://smalltalkhub.com/#!/~OS

Sept. 8, 2016

Re: [Pharo-users] Performance vs Ruby performance

by Dimitris Chloupis

It does not matter. When it comes to performance the workflow is always the same whatever the language you use. 1. Profile the code see where it consume most CPU cycles 2. Can you improve the code to remove unnecessary processing ? You will be surprised how many times its your code and not the language that is slow 3. If it's not your code can you find a library written in C that is optimized for speed ? 4. If no then write the code in C compile it as shared library and use it from the language of your choice using an FFI Basically when a VM in a dynamic language finds a call to a C shared library using the FFI it will freeze everything and give priority to the C code to execute the call to its native speed. Then after the execution the VM resumes. There is an overhead however for making the call. Because speed depends on the factors I described above for many experienced coders general benchmarks are completely useless. Speed in the end is just machine code with as less instructions as possible using most hardware acceleration as possible. Talking about hardware acceleration if you try to do the same processing on a list of data which is very large in parallel don't even consider C , instead go directly to GPU because it can accelerate even up to 100 times compared to CPU. But in the end will depend on how much speed you really need. If you indeed need it then you can accelerate your code using the GPU with the help of CUDA or OpenCL. Remember however that optimizing is the root of true evil , it will make your code ugly, hard to read, difficult to extend and much more buggy. PS: the vast majority of benchmarks including the ones linked by Clement use just code written in the language tested also using the library that the language comes with. That means that they use none of the normal optimizations I described above and hence they cannot be considered practical realistic scenarios. On Thu, 8 Sep 2016 at 02:30, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Hello, > > How is Pharo compared with Ruby in terms of performance? Has someone done > some comparison benchmark? If yes, that was done with other platforms? > > Regards, > VItor >

Sept. 8, 2016

Re: [Pharo-users] Performance vs Ruby performance

by ClÃ©ment Bera

What ruby runtime exactly ? The standard ruby interpreter, rubinius, JRuby ? What do you mean by performance ? Smallest time to run long computation ? Latency for web servers ? Pauses in real time applications ? The standard ruby interpreter is really slow (likely ~100 times slower than the Pharo 5 VM), now it binds directly multiple C librairies, such as the regex librairy, while these librairies are written in Smalltalk in Pharo. So if you measure regex performance I am pretty sure that ruby is at least 10 times faster, if not 100 times. So basically it depends on what benchmark you are measuring. We don't do cross languages benchmarks in our servers, only versus other Smalltalks. That website (http://benchmarksgame.alioth.debian.org/) compares ruby and JRuby to VW which has similar speed to Pharo 5. On Thu, Sep 8, 2016 at 1:28 AM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Hello, > > How is Pharo compared with Ruby in terms of performance? Has someone done > some comparison benchmark? If yes, that was done with other platforms? > > Regards, > VItor >

Sept. 8, 2016

Re: [Pharo-users] [ANN] Territorial Re-Licensing

by Ben Coman

Hi Hernan, Thanks for your balanced response. Licensing discussion can be boring but also crucial, hence the sometimes religious views on it. Like a lot of things, from a distance it seems easy - but the devil is in the details. Consider anyway that "Territorial" may otherwise have been a single blip in your first [ANN] post, but its now had more exposure. I hope you don't mind I follow up with one more post that has been sitting almost complete in Drafts folder a few days, after researching some interesting points. cheers -ben On Thu, Sep 8, 2016 at 12:00 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > I consider GNU AGPL v3 a fair license choice which protects somehow authors. > After some talks with friends today, I began to consider it useless for a > niche community like Smalltalk *and* solo projects. I then read all your > mails, many posts in other communities, and finally asked for advices. > Conclusion: The ideal license option for me was not yet invented. > > Now about parasite behavior and easy living for freeloaders. > > - I doubt Smalltalkers are in position for doing anything valuable against > parasites. GPL scares a niche community. All of us having MIT code published > can be stealed and we have no legal options to defend our work/authorship. > That should be addressed one day. > > - However, I would like one day to read people releasing software under > whatever license they want and not to be pointed them. That's a matter of > freedom. I feel we are far away from there. > > - I hope we can talk about interesting Territorial features, what do you > need, what could be modeled better, etc. Licensing is boring, really. > > I re-licensed Territorial to MIT for the nice Pharo people, for the nice > Smalltalkers, people who helped me here in mailing lists, or sending > supportive private messages, and for cool users with nice intentions. > > HernÃ¡n > > PS: Updated User Manual: http://bit.ly/2c4RrCJ > > >

Sept. 8, 2016

Re: [Pharo-users] Profiling

by Ben Coman

On Thu, Sep 8, 2016 at 11:37 AM, Ben Coman <btc(a)openinworld.com> wrote: > - 9989 tallies, 10003 msec. > > **Tree** > -------------------------------- > Process: other processes > -------------------------------- > 99.2% {9928ms} ProcessorScheduler class>>startUp > 99.2% {9928ms} ProcessorScheduler class>>idleProcess > **Leaves** > 99.2% {9928ms} ProcessorScheduler class>>idleProcess > > **Memory** > old +0 bytes > young -223,912 bytes > used -223,912 bytes > free +223,912 bytes > > **GCs** > full 0 totalling 0ms (0.0% uptime) > incr 2 totalling 6ms (0.0% uptime), avg 3.0ms > tenures 0 > root table 0 overflows > > On Thu, Sep 8, 2016 at 9:44 AM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: >> Hello, >> >> While profiling some I/O code that takes ~20 seconds to execute under my >> local image, the report says that about ~13 seconds is waste on >> OtherProcesses -> ProcessorScheduler class>>idleProcess. I could not >> understand what this idleProcess do by looking at the code. First I thought >> this could be time waiting the I/O operation to terminate, but that don't >> make much sense because I have the same code on a Digital Ocean Doplet and >> it takes ~6 seconds to execute. >> >> Can someone help me understand what does this time on idleProcess means? > > I don't have an exact answer for you, but a comparative example... > > Tools > Time Profiler... > 10 seconds wait > Full report... > ========================================== > - 9989 tallies, 10003 msec. > > **Tree** > -------------------------------- > Process: other processes > -------------------------------- > 99.2% {9928ms} ProcessorScheduler class>>startUp > 99.2% {9928ms} ProcessorScheduler class>>idleProcess > **Leaves** > 99.2% {9928ms} ProcessorScheduler class>>idleProcess > > **Memory** > old +0 bytes > young -223,912 bytes > used -223,912 bytes > free +223,912 bytes > > **GCs** > full 0 totalling 0ms (0.0% uptime) > incr 2 totalling 6ms (0.0% uptime), avg 3.0ms > tenures 0 > root table 0 overflows > ========================================== > > Now over that time, Windows 7 Task Manager showed Pharo process CPU load of 0%, > indicating the 9.9 seconds spent in idleProcess has no impact on performance. > Or put another way, for 99.2% of that 10 seconds Pharo was *not* busy. > > Applying that to your results, I would guess that for 73.3% of that 20 > seconds you were waiting on I/O. > > To find your performance issues, follow down the percentages for where > there are big jumps without splits. > That is, ignore jumps where the splits add up to the parent. > For example 14.3 + 10.8 ==> 25.1 - so no lost performance here... > 25.0% {4656ms} TweetsServiceRestConsumer>>fetchLastTweetsUpTo:fromHandler: > 14.3% {2653ms} OAuthProvider>>httpGet: > | > 10.8% {2002ms} NeoJSONObject class>>fromString: > > Your biggest loss in a linear line seems to be... > 5.6% {1041ms} NeoJSONReader>>parseValue > to > 1.5% {285ms} NeoJSONReader>>parseMap > > > I am curious about the recursive calls to > ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > and multiple accumulations from DelayExperimentalSpinScheduler>>unschedule: > but that method doesn't really do a lot. I wouldn't expect the > whileTrue loop to be spinning much, but you could examine that by > > > You might try another scheduler... > World>System>Settings>System>Delay Scheduler Another experiment might try could be divide-and-conquer by examining a sample of what is returned by... 10.8% {2002ms} NeoJSONObject class>>fromString: and return a similar constant. cheers -ben

Sept. 8, 2016

Re: [Pharo-users] Profiling

by Ben Coman

Ahhh... gmail pre-emptive send strikes again.... To continue... I am curious about the recursive calls to ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer and multiple accumulations from DelayExperimentalSpinScheduler>>unschedule: but that method doesn't really do a lot. I wouldn't expect the whileTrue loop to be spinning much, but you could examine that by trying something like... Object subclass: #SpinCount instanceVariableNames: 'counter' classVariableNames: '' package: 'Play' SpinCount>>initialize counter := 0. SpinCount>>count counter := counter + 1. SpinCount>>printOn: aStream super printOn: aStream. aStream nextPut: $=. counter printOn: aStream. DelayMicrosecondScheduler subclass: #DelayExperimentalSpinScheduler instanceVariableNames: '' classVariableNames: 'Tally' package: 'Kernel-Processes' DelayExperimentalSpinScheduler class >> startTally Tally := WaitfreeQueue new. DelayExperimentalSpinScheduler class >> endTally |result finalTally| finalTally := Tally. Tally := nil. result := OrderedCollection new. finalTally flush: [ :item | result add: item ]. ^ result DelayExperimentalSpinScheduler >> unschedule: aDelay |spinCount| "self startTally" "self endTally inspect" spinCount := SpinCount new. Tally ifNotNil: [Tally nextPut: spinCount]. aDelay schedulerBeingWaitedOn ifTrue: [^self error: 'This Delay has already been scheduled.']. [ Tally ifNotNil: [spinCount count]. scheduledDelay == nil ifTrue: [ scheduledDelay := aDelay. timingSemaphore signal. ^self]. true. ] whileTrue. Actually, I wonder does the "timingSemaphore signal" invoking the priority 80 DelaySchedulingProcess to wake up and run above the priority of the profiler? So all of that activity gets attributed to #unschedule: ??? cheers -ben

Sept. 8, 2016

[ANN] Territorial Re-Licensing

by HernÃ¡n Morales Durand

I consider GNU AGPL v3 a fair license choice which protects somehow authors. After some talks with friends today, I began to consider it useless for a niche community like Smalltalk *and* solo projects. I then read all your mails, many posts in other communities, and finally asked for advices. Conclusion: The ideal license option for me was not yet invented. Now about parasite behavior and easy living for freeloaders. - I doubt Smalltalkers are in position for doing anything valuable against parasites. GPL scares a niche community. All of us having MIT code published can be stealed and we have no legal options to defend our work/authorship. That should be addressed one day. - However, I would like one day to read people releasing software under whatever license they want and not to be pointed them. That's a matter of freedom. I feel we are far away from there. - I hope we can talk about interesting Territorial features, what do you need, what could be modeled better, etc. Licensing is boring, really. I re-licensed Territorial to MIT for the nice Pharo people, for the nice Smalltalkers, people who helped me here in mailing lists, or sending supportive private messages, and for cool users with nice intentions. HernÃ¡n PS: Updated User Manual: http://bit.ly/2c4RrCJ

Sept. 8, 2016

Re: [Pharo-users] Profiling

by Ben Coman

- 9989 tallies, 10003 msec. **Tree** -------------------------------- Process: other processes -------------------------------- 99.2% {9928ms} ProcessorScheduler class>>startUp 99.2% {9928ms} ProcessorScheduler class>>idleProcess **Leaves** 99.2% {9928ms} ProcessorScheduler class>>idleProcess **Memory** old +0 bytes young -223,912 bytes used -223,912 bytes free +223,912 bytes **GCs** full 0 totalling 0ms (0.0% uptime) incr 2 totalling 6ms (0.0% uptime), avg 3.0ms tenures 0 root table 0 overflows On Thu, Sep 8, 2016 at 9:44 AM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Hello, > > While profiling some I/O code that takes ~20 seconds to execute under my > local image, the report says that about ~13 seconds is waste on > OtherProcesses -> ProcessorScheduler class>>idleProcess. I could not > understand what this idleProcess do by looking at the code. First I thought > this could be time waiting the I/O operation to terminate, but that don't > make much sense because I have the same code on a Digital Ocean Doplet and > it takes ~6 seconds to execute. > > Can someone help me understand what does this time on idleProcess means? I don't have an exact answer for you, but a comparative example... Tools > Time Profiler... 10 seconds wait Full report... ========================================== - 9989 tallies, 10003 msec. **Tree** -------------------------------- Process: other processes -------------------------------- 99.2% {9928ms} ProcessorScheduler class>>startUp 99.2% {9928ms} ProcessorScheduler class>>idleProcess **Leaves** 99.2% {9928ms} ProcessorScheduler class>>idleProcess **Memory** old +0 bytes young -223,912 bytes used -223,912 bytes free +223,912 bytes **GCs** full 0 totalling 0ms (0.0% uptime) incr 2 totalling 6ms (0.0% uptime), avg 3.0ms tenures 0 root table 0 overflows ========================================== Now over that time, Windows 7 Task Manager showed Pharo process CPU load of 0%, indicating the 9.9 seconds spent in idleProcess has no impact on performance. Or put another way, for 99.2% of that 10 seconds Pharo was *not* busy. Applying that to your results, I would guess that for 73.3% of that 20 seconds you were waiting on I/O. To find your performance issues, follow down the percentages for where there are big jumps without splits. That is, ignore jumps where the splits add up to the parent. For example 14.3 + 10.8 ==> 25.1 - so no lost performance here... 25.0% {4656ms} TweetsServiceRestConsumer>>fetchLastTweetsUpTo:fromHandler: 14.3% {2653ms} OAuthProvider>>httpGet: | 10.8% {2002ms} NeoJSONObject class>>fromString: Your biggest loss in a linear line seems to be... 5.6% {1041ms} NeoJSONReader>>parseValue to 1.5% {285ms} NeoJSONReader>>parseMap I am curious about the recursive calls to ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer and multiple accumulations from DelayExperimentalSpinScheduler>>unschedule: but that method doesn't really do a lot. I wouldn't expect the whileTrue loop to be spinning much, but you could examine that by You might try another scheduler... World>System>Settings>System>Delay Scheduler

Sept. 8, 2016

Profiling

by Vitor Medina Cruz

Hello, While profiling some I/O code that takes ~20 seconds to execute under my local image, the report says that about ~13 seconds is waste on OtherProcesses -> ProcessorScheduler class>>idleProcess. I could not understand what this idleProcess do by looking at the code. First I thought this could be time waiting the I/O operation to terminate, but that don't make much sense because I have the same code on a Digital Ocean Doplet and it takes ~6 seconds to execute. Can someone help me understand what does this time on idleProcess means? The full report is: - 18407 tallies, 18605 msec. **Tree** -------------------------------- Process: (40s) Morphic UI Process: nil -------------------------------- 25.1% {4663ms} UndefinedObject>>DoIt 25.1% {4663ms} TweetsServiceRestConsumer(TweetsService)>>hashesTop:usingLastTweetsUpTo:fromHandler: 25.0% {4656ms} TweetsServiceRestConsumer>>fetchLastTweetsUpTo:fromHandler: 14.3% {2653ms} OAuthProvider>>httpGet: |14.3% {2653ms} ZnOAuth1Service>>httpGet:using: | 14.3% {2653ms} ZnOAuth1Service>>executeRequest:token: | 14.3% {2653ms} ZnOAuth1Service>>executeRequest:token:followRedirects: | 14.2% {2646ms} ZnClient>>execute | 14.2% {2646ms} ZnClient>>withProgressDo: | 14.2% {2646ms} ZnSignalProgress class(DynamicVariable class)>>value:during: | 14.2% {2646ms} ZnSignalProgress(DynamicVariable)>>value:during: | 14.2% {2646ms} BlockClosure>>ensure: | 14.2% {2646ms} ZnSignalProgress(DynamicVariable)>>value:during: | 14.2% {2646ms} ZnClient>>withProgressDo: | 14.2% {2646ms} ZnClient>>execute | 14.2% {2646ms} ZnClient>>executeWithTimeout | 14.2% {2646ms} ZnClient>>withTimeoutDo: | 14.2% {2646ms} ZnConnectionTimeout class(DynamicVariable class)>>value:during: | 14.2% {2646ms} ZnConnectionTimeout(DynamicVariable)>>value:during: | 14.2% {2646ms} BlockClosure>>ensure: | 14.2% {2646ms} ZnConnectionTimeout(DynamicVariable)>>value:during: | 14.2% {2646ms} ZnClient>>withTimeoutDo: | 14.2% {2646ms} ZnClient>>executeWithTimeout | 14.2% {2646ms} BlockClosure>>on:do: | 14.2% {2646ms} ZnClient>>executeWithTimeout | 14.2% {2646ms} ZnClient>>executeWithRetriesRemaining: | 14.2% {2644ms} BlockClosure>>on:do: | 14.2% {2644ms} ZnClient>>executeWithRetriesRemaining: | 14.2% {2644ms} ZnClient>>executeWithRedirectsRemaining: | 14.2% {2641ms} ZnClient>>getConnectionAndExecute | 13.8% {2569ms} BlockClosure>>ensure: | 13.8% {2569ms} ZnClient>>getConnectionAndExecute | 13.8% {2569ms} ZnClient>>executeRequestResponse | 13.8% {2569ms} ZnClient>>readResponse | 13.8% {2569ms} ZnResponse class(ZnMessage class)>>readFrom: | 13.8% {2569ms} ZnResponse(ZnMessage)>>readFrom: | 13.8% {2559ms} ZnResponse>>readEntityFrom: | 13.8% {2559ms} ZnResponse(ZnMessage)>>readEntityFrom: | 13.8% {2559ms} ZnEntityReader>>readEntity | 13.8% {2559ms} ZnEntityReader>>readEntityFromStream | 13.7% {2555ms} ZnEntityReader>>readFrom:usingType:andLength: | 13.7% {2555ms} ZnEntity class>>readFrom:usingType:andLength: | 13.7% {2555ms} ZnStringEntity>>readFrom: | 13.7% {2550ms} BlockClosure>>on:do: | 13.7% {2550ms} ZnStringEntity>>readFrom: | 13.7% {2550ms} ZnUTF8Encoder>>readInto:startingAt:count:fromStream: | 13.7% {2550ms} ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: | 13.7% {2550ms} ZnLimitedReadStream>>readInto:startingAt:count: | 13.7% {2547ms} ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:startingAt:count: | 13.7% {2547ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | 9.0% {1669ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | |5.8% {1076ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | |3.6% {671ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | | |1.8% {337ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | | | |1.2% {225ms} BlockClosure>>on:do: | | | | | 1.2% {225ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | | | | 1.2% {225ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData | | | | | 1.2% {225ms} Socket>>waitForDataFor: | | | | | 1.2% {225ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: | | | | | 1.2% {225ms} Semaphore>>waitTimeoutMSecs: | | | | | 1.2% {225ms} DelayWaitTimeout>>wait | | | | | 1.2% {225ms} BlockClosure>>ensure: | | | | | 1.2% {225ms} DelayWaitTimeout>>wait | | | | | 1.1% {196ms} DelayWaitTimeout(Delay)>>unschedule | | | | | 1.1% {196ms} DelayExperimentalSpinScheduler>>unschedule: | | | |1.8% {335ms} BlockClosure>>on:do: | | | | 1.8% {335ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | | | 1.8% {335ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData | | | | 1.8% {335ms} Socket>>waitForDataFor: | | | | 1.8% {335ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: | | | | 1.8% {335ms} Semaphore>>waitTimeoutMSecs: | | | | 1.8% {335ms} DelayWaitTimeout>>wait | | | | 1.8% {335ms} BlockClosure>>ensure: | | | | 1.8% {335ms} DelayWaitTimeout>>wait | | | | 1.5% {273ms} DelayWaitTimeout(Delay)>>unschedule | | | | 1.5% {273ms} DelayExperimentalSpinScheduler>>unschedule: | | |2.2% {405ms} BlockClosure>>on:do: | | | 2.2% {405ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | | 2.2% {405ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData | | | 2.2% {405ms} Socket>>waitForDataFor: | | | 2.2% {405ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: | | | 2.2% {405ms} Semaphore>>waitTimeoutMSecs: | | | 2.2% {405ms} DelayWaitTimeout>>wait | | | 2.2% {405ms} BlockClosure>>ensure: | | | 2.2% {405ms} DelayWaitTimeout>>wait | | | 1.7% {314ms} DelayWaitTimeout(Delay)>>unschedule | | | 1.7% {314ms} DelayExperimentalSpinScheduler>>unschedule: | |3.2% {592ms} BlockClosure>>on:do: | | 3.2% {592ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | | 3.2% {592ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData | | 3.2% {592ms} Socket>>waitForDataFor: | | 3.2% {592ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: | | 3.2% {592ms} Semaphore>>waitTimeoutMSecs: | | 3.2% {592ms} DelayWaitTimeout>>wait | | 3.2% {592ms} BlockClosure>>ensure: | | 3.2% {592ms} DelayWaitTimeout>>wait | | 2.3% {429ms} DelayWaitTimeout(Delay)>>unschedule | | 2.3% {429ms} DelayExperimentalSpinScheduler>>unschedule: | 4.7% {876ms} BlockClosure>>on:do: | 4.7% {876ms} ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer | 4.7% {876ms} ZdcSecureSocketStream(ZdcAbstractSocketStream)>>socketWaitForData | 4.7% {876ms} Socket>>waitForDataFor: | 4.7% {876ms} Socket>>waitForDataFor:ifClosed:ifTimedOut: | 4.7% {876ms} Semaphore>>waitTimeoutMSecs: | 4.7% {876ms} DelayWaitTimeout>>wait | 4.7% {876ms} BlockClosure>>ensure: | 4.7% {876ms} DelayWaitTimeout>>wait | 2.9% {532ms} DelayWaitTimeout(Delay)>>unschedule | |2.9% {532ms} DelayExperimentalSpinScheduler>>unschedule: | 1.4% {268ms} primitives 10.8% {2002ms} NeoJSONObject class>>fromString: 10.8% {2002ms} NeoJSONReader>>next 10.8% {2002ms} NeoJSONReader>>parseValue 10.8% {2002ms} NeoJSONReader>>parseList 10.8% {2002ms} Array class(SequenceableCollection class)>>streamContents: 10.8% {2002ms} Array class(SequenceableCollection class)>>new:streamContents: 10.8% {2002ms} NeoJSONReader>>parseList 10.8% {2002ms} NeoJSONReader>>parseListElementsDo: 10.8% {2002ms} NeoJSONReader>>parseListDo: 10.8% {2002ms} NeoJSONReader>>parseListElementsDo: 10.8% {2002ms} NeoJSONReader>>parseValue 10.8% {2002ms} NeoJSONReader>>parseMap 10.8% {2002ms} NeoJSONReader>>parseMapKeysAndValuesDo: 10.8% {2002ms} NeoJSONReader>>parseMapKeysDo: 10.8% {2002ms} NeoJSONReader>>parseMapDo: 10.7% {1994ms} NeoJSONReader>>parseMapKeysDo: 9.6% {1785ms} NeoJSONReader>>parseMapKeysAndValuesDo: |9.2% {1717ms} NeoJSONReader>>parseValue | 8.6% {1600ms} NeoJSONReader>>parseMap | 8.6% {1600ms} NeoJSONReader>>parseMapKeysAndValuesDo: | 8.6% {1600ms} NeoJSONReader>>parseMapKeysDo: | 8.6% {1600ms} NeoJSONReader>>parseMapDo: | 8.5% {1577ms} NeoJSONReader>>parseMapKeysDo: | 6.4% {1187ms} NeoJSONReader>>parseMapKeysAndValuesDo: | |5.6% {1041ms} NeoJSONReader>>parseValue | | 3.8% {708ms} NeoJSONReader>>parseList | | 3.8% {706ms} Array class(SequenceableCollection class)>>streamContents: | | 3.8% {706ms} Array class(SequenceableCollection class)>>new:streamContents: | | 3.7% {693ms} NeoJSONReader>>parseList | | 3.7% {693ms} NeoJSONReader>>parseListElementsDo: | | 3.7% {693ms} NeoJSONReader>>parseListDo: | | 3.7% {689ms} NeoJSONReader>>parseListElementsDo: | | 3.7% {689ms} NeoJSONReader>>parseValue | | 3.7% {687ms} NeoJSONReader>>parseMap | | 3.7% {687ms} NeoJSONReader>>parseMapKeysAndValuesDo: | | 3.7% {687ms} NeoJSONReader>>parseMapKeysDo: | | 3.7% {687ms} NeoJSONReader>>parseMapDo: | | 3.6% {672ms} NeoJSONReader>>parseMapKeysDo: | | 3.0% {550ms} NeoJSONReader>>parseMapKeysAndValuesDo: | | 2.6% {486ms} NeoJSONReader>>parseValue | | 1.5% {285ms} NeoJSONReader>>parseMap | | 1.5% {285ms} NeoJSONReader>>parseMapKeysAndValuesDo: | | 1.5% {285ms} NeoJSONReader>>parseMapKeysDo: | | 1.5% {285ms} NeoJSONReader>>parseMapDo: | | 1.5% {285ms} NeoJSONReader>>parseMapKeysDo: | | 1.4% {252ms} NeoJSONReader>>parseMapKeysAndValuesDo: | | 1.3% {236ms} NeoJSONReader>>parseValue | | 1.0% {193ms} NeoJSONReader>>parseMap | | 1.0% {193ms} NeoJSONReader>>parseMapKeysAndValuesDo: | | 1.0% {193ms} NeoJSONReader>>parseMapKeysDo: | | 1.0% {188ms} NeoJSONReader>>parseMapDo: | 1.9% {347ms} NeoJSONReader>>parsePropertyName | 1.1% {196ms} NeoJSONReader>>parseValue | 1.0% {189ms} NeoJSONReader>>parseString 1.0% {189ms} NeoJSONReader>>parsePropertyName -------------------------------- Process: other processes -------------------------------- 73.2% {13628ms} ProcessorScheduler class>>startUp |73.2% {13628ms} ProcessorScheduler class>>idleProcess 1.4% {259ms} WeakArray class>>restartFinalizationProcess 1.4% {259ms} WeakArray class>>finalizationProcess 1.4% {257ms} primitives **Leaves** 73.3% {13631ms} ProcessorScheduler class>>idleProcess 10.0% {1861ms} DelayExperimentalSpinScheduler>>unschedule: 3.1% {581ms} DelayWaitTimeout>>wait 1.4% {257ms} WeakArray class>>finalizationProcess 1.0% {191ms} WeakSet>>scanFor: **Memory** old +16,777,216 bytes young -17,303,480 bytes used -526,264 bytes free +17,303,480 bytes **GCs** full 1 totalling 247ms (1.0% uptime), avg 247.0ms incr 127 totalling 199ms (1.0% uptime), avg 2.0ms tenures 480,033 (avg 0 GCs/tenure) root table 0 overflows Thanks in advance, Vitor

Sept. 8, 2016