Great work Ben!
> On 10 Mar 2015, at 17:44, Ben Coman <[email protected]> wrote:
>
> This is solved with the integration of issue 14353 into build 40548.
>
> On an OSX > Virtualbox > LinuxMint17 with the following script...
> for i in `seq 1 10` ;
> do
> (time $MYPHAROVM $MYIMAGE \
> eval "(Delay forSeconds: 1) wait") 2>&1 > /dev/null | grep real
> done
>
> Build 40547 gives...
> real 0m1.288s
> real 0m1.256s
> real 0m1.258s
> real 0m0.254s
> real 0m0.269s
> real 0m0.274s
> real 0m0.260s
> real 0m0.245s
> real 0m0.254s
> real 0m1.260s
>
> Build 40548 gives...
> real 0m1.285s
> real 0m1.259s
> real 0m1.260s
> real 0m1.260s
> real 0m1.280s
> real 0m1.267s
> real 0m1.265s
> real 0m1.293s
> real 0m1.267s
> real 0m1.278s
>
> HTH,
> cheers -ben
>
>
> On Mon, Mar 2, 2015 at 12:08 PM, Ben Coman <[email protected]
> <mailto:[email protected]>> wrote:
>
> This is not going to get as much use before Release as I had hoped, so I
> refactored it to be able to easily switch between the existing and new code
> by making two schedulers...
> * DelayMillisecondScheduler - essentially the existing code
> * DelayMicrosecondScheduler - based off new primitive
> which are switchable on the fly via a System Setting.
>
> To try to make it easier to review, I've separated changes into three stages:
> * SLICE.10 accumulates changes the Delay class to add some better semantics
> to instance variables and method renames
> * SLICE.14 accumulates changes to split DelayScheduler into two subclasses
> for the two different schedulers (use the incoming code in the merge conflict)
> * SLICE.17 accumulates changes to modify DelayMicrosecondScheduler, plus a
> couple of polishing things.
>
> I've added some review notes to the issue
> https://pharo.fogbugz.com/default.asp?14353
> <https://pharo.fogbugz.com/default.asp?14353>
>
> fyi, Tomorrow I start a new job at Buewaters Power Station [1] (2 x 208MW
> generators). They've been without an electrical engineer for three months
> leading up to their annual outage in five weeks, so I'm probably flat there
> playing catch-up for the next two months. Today (GMT+8) would be a really
> good time to engage me with feedback and queries. I'll try to hang out on
> IRC as much as possible to speed up discussion.
>
> [1] http://www.bluewatersps.com.au/ <http://www.bluewatersps.com.au/>
>
> cheers -ben
>
>
>
> On Mon, Mar 2, 2015 at 3:09 AM, stepharo <[email protected]
> <mailto:[email protected]>> wrote:
>
> Please help us to push ben code.
>
>
>
> -------- Message transféré --------
> Sujet : Re: [Pharo-dev] Super fast delay
> Date : Wed, 25 Feb 2015 02:00:25 +0800
> De : Ben Coman <[email protected]>
> Répondre à : Pharo Development List <[email protected]
> <mailto:[email protected]>>
> Pour : Pharo Development List <[email protected]
> <mailto:[email protected]>>
>
>
> I've updated this fix for build 40504. The following slice is read for
> review.
> SLICE-Issue-14353-Delay-refactoring-part-2---change-from-milliseconds-to-microseconds-BenComan.6
>
> Even if you do not feel up to reviewing the code, it would be good for a few
> people to merge this to get a broad sample of symptoms fixed or caused.
>
> 1. Open up Monticello and get ready to load the above slice from Pharo4Inbox
> repository.
> 2. In a workspace, do "Delay stopTimerEventLoop". Ignore the
> #intercyclePause: message that stream by.
> 3. Merge slice.
> 4. In a workspace, do "Delay startTimerEventLoop". The stream of
> #interCyclePause message should fade.
> 5. Operate as you normally would. Test some cases that previously caused an
> error.
>
> cheers -ben
>
> On Thu, Feb 19, 2015 at 11:17 PM, Ben Coman <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> On Thu, Feb 19, 2015 at 9:50 PM, Ben Coman <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> On Mon, Feb 16, 2015 at 4:01 PM, Holger Hans Peter Freyther
> <[email protected] <mailto:[email protected]>> wrote:
> On Thu, Oct 30, 2014 at 06:32:48PM -0400, stepharo wrote:
>
> Good Morning Ben, Stef,
>
> > We really need people to have a look at the code of Ben.
>
> I downloaded a Pharo-4 image today and executed:
>
> To clarify. The fix is not yet in Pharo-4.
>
>
> time pharo --nodisplay --headless ./Pharo-40490.image eval "(Delay
> forSeconds: 5) wait"
> a Delay(5000 msecs)
>
> real 0m1.254s
> user 0m1.192s
> sys 0m0.060s
>
>
> So the first delay doesn't appear to wait the five seconds. I
> would like to work on kqueue/epoll and remove polling and it
> looks this involves code with Delay as well. I wonder if you
> could provide an overview of what needs to be done and what is
> done?
>
> The pre-requisite issue 14942 is waiting for review. It really should take
> only 10 minutes to review...
> 1. In latest Pharo 4, inspect "Delay newCodeEnabled" and observe that it is
> "true".
> 2. Open the Pharo4Inbox and filter on 14942.
> 3. Select newest slice and <Merge>.
> 4. Observe the diff shows all "false" parts removed (it doesn't really get
> much simpler than this to review).
> 5. Click <merge> to finish.
> 6. Observe the image continues to run smoothly.
> 7. Report your observations on https://pharo.fogbugz.com/default.asp?14942
> <https://pharo.fogbugz.com/default.asp?14942>
>
> btw, after the cleanup done by Issue 14942, Issue 14966 can delete ten class
> variables from Delay.
> When 14942 is integrated, can 14966 be integrated very soon after that. I am
> basing the change of Delay to microsecond delay off 14966.
> cheers -ben
>
>
>
>
> I need to refresh myself on the fix I did back in 2-Dec. Its languished
> while some support infrastructure was added to help the system ride-through
> the change.
>
> cheers -ben
>
>
>
>
>
