On Wed, Nov 18, 2015 at 3:10 PM, Ben Coman <btc@openinworld.com> wrote:

From Playground...
a BenchmarkResult(1,942,473 iterations in 1 minute 47 seconds 237
milliseconds. 18,114 per second)

Now I haven't thought hard enough about the following to know if its
the right solution, but just an early share...
changing...
�� ] forkAt: Processor activePriority.
to...
�� ] forkAt: Processor activePriority - 1.
in�� #styleInBackgroundProcess:�� has a positive impact.

Interesting.

Just somehow this seems more like a workaround.

I'd really like to find out why rubric creates zombie processes when styling and how do these processes affect the delay scheduling.

Replacing, in the code I previously send, the creation of a Rubric editor with just the code for styling leads to no delay.

(RubSHTextStylerST80 new styleInBackgroundProcess: '1+1' asText)

Ideally I'd like to find some code, independent of rubric that exhibits the bug.

Something in the line of this script��http://ws.stfx.eu/1P51Y1WBN9RJ , which for now does not produce any delay.

For the moment I'll disable #testAllExamples so see if this actually fixes the blocking issue from the CI.

Cheers,

Andrei

��

cheers -ben

On Wed, Nov 18, 2015 at 7:09 PM, Max Leske <maxleske@gmail.com> wrote:
> a BenchmarkResult(5,057,441 iterations in 3 minutes 26 seconds 74 milliseconds. 24,542 per second)
>
> ./pharo Pharo.image eval�� 205,98s user 2,07s system 100% cpu 3:27,44 total
>
>> On 18 Nov 2015, at 11:48, Andrei Chis <chisvasileandrei@gmail.com> wrote:
>>
>> Can you try the script below in the latest Pharo image and let me know how much does it take to execute on your machine:
>>
>>�� |duration benchmarkResult|
>>�� 100 timesRepeat: [
>>�� RubScrolledTextMorph new
>>�� model: (RubScrolledTextModel new setInitialText: '1+1'; yourself);
>>�� beForSmalltalkScripting;
>>�� yourself
>>�� ] .
>>
>>�� duration := 100 milliSeconds.
>>�� benchmarkResult := [ 100 factorial ] benchFor: duration.
>>
>> In my case it takes around 1 minute. The inner loop finishes immediately and then most time is spend executing the benchmark.
>>
>> At the end I get the following result:
>> "a BenchmarkResult(2,060,386 iterations in 1 minute 7 seconds 498 milliseconds. 30,525 per second)"
>>
>> So the benchmark is executed for over one minute before the delay expires.
>>
>>
>>
>
>