Real Slowdown of InputSensor between 3.8 and 3.9

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Real Slowdown of InputSensor between 3.8 and 3.9

Stéphane Ducasse-3
Hi

I was surprised by the slowdown of one of my little applications and  
I messageTalliedThem
wtih exactly the same code on 3.8 and 3.9

Here are the results:

MessageTally spyOn:  [ | bdb |
                        BDBase initialize.
                        BDBase resetBaseNamed: #BD.
                        bdb := BDBase new name: #BD.
                        bdb importMostRecentXML.]






On 38

Time millisecondsToRun: [ | bdb |
                BDBase initialize.
                BDBase resetBaseNamed: #BD.
                bdb := BDBase new name: #BD.
                bdb importMostRecentXML.]  1677


**Leaves**
3.2% {56ms} MultiByteFileStream>>next
3.2% {56ms} MultiByteFileStream>>doConversion
3.0% {52ms} UTF8TextConverter>>nextFromStream:
3.0% {52ms} SmallInteger(Number)>>negative
2.9% {51ms} MultiByteFileStream(StandardFileStream)>>basicNext
2.9% {51ms} SAXDriver(XMLTokenizer)>>next
2.9% {51ms} MultiByteFileStream>>converter
2.6% {45ms} ByteSymbol class(String class)>>stringHash:initialHash:
2.5% {44ms} MultiByteFileStream>>wantsLineEndConversion
2.1% {37ms} MultiByteFileStream(StandardFileStream)>>isBinary

on 39

- 21243 tallies, 21304 msec.

**Tree**
100.0% {21304ms} BDBase>>importMostRecentXML
   99.8% {21261ms} BDBase>>importXMLFromFileName:
     99.8% {21261ms} BDXMLImporter>>importFileNamed:
       99.8% {21261ms} BDXMLImporter>>importStream:
         96.5% {20558ms} BDXMLImporter>>importXMLDoc:
           |89.2% {19003ms} EventSensor(InputSensor)>>shiftPressed
           |  |89.2% {19003ms} EventSensor>>primMouseButtons
           |  |  89.2% {19003ms} EventSensor>>wait2ms
           |  |    89.1% {18982ms} Delay>>wait
           |  |      89.1% {18982ms} primitives
           |7.3% {1555ms} BDXMLImporter>>importBD:
         3.3% {703ms} XMLDOMParser class>>parseDocumentFrom:
           3.3% {703ms} XMLDOMParser class(SAXHandler class)
 >>parseDocumentFrom:
             3.3% {703ms} XMLDOMParser(SAXHandler)>>parseDocument
               3.3% {703ms} SAXDriver(XMLTokenizer)>>nextEntity
                 3.2% {682ms} SAXDriver(XMLTokenizer)>>nextNode
                   3.2% {682ms} SAXDriver(XMLTokenizer)>>nextTag
                     2.7% {575ms} SAXDriver(XMLTokenizer)
 >>nextAttributeInto:namespaces:
**Leaves**
89.1% {18982ms} Delay>>wait

**Memory**
        old +4,748,696 bytes
        young -3,868,600 bytes
        used +880,096 bytes
        free +2,512,576 bytes

**GCs**
        full 1 totalling 83ms (0.0% uptime), avg 83.0ms
        incr 541 totalling 200ms (1.0% uptime), avg 0.0ms
        tenures 25 (avg 21 GCs/tenure)
        root table 0 overflows

Time millisecondsToRun: [ | bdb |
                        BDBase initialize.
                        BDBase resetBaseNamed: #BD.
                        bdb := BDBase new name: #BD.
                        bdb importMostRecentXML.] 21182


So it seems that some logic were changed in the inputSensor. When I  
commented InputSensor default shiftPressed ifTrue: [self halt.]. in  
the import method

importXMLDoc: aXMLDoc

        aXMLDoc elements first elements do:
                [:each | Transcript show: '.'. "InputSensor default shiftPressed  
ifTrue: [self halt.]."
                                self importBD: each].

Now my benchmarck give me.
Time millisecondsToRun: [ | bdb |
                        BDBase initialize.
                        BDBase resetBaseNamed: #BD.
                        bdb := BDBase new name: #BD.
                        bdb importMostRecentXML.] 1643

I thought that it is worth to share.

Stef




Reply | Threaded
Open this post in threaded view
|

RE: Real Slowdown of InputSensor between 3.8 and 3.9

Gary Chambers-4
Changed that is my image some time ago (in EventSensor) for the same
reasons...

shiftPressed
        "Answer whether the shift key on the keyboard is being held down."

        ^mouseButtons anyMask: 8

controlKeyPressed
        "Answer whether the control key on the keyboard is being held down."

        ^mouseButtons anyMask: 16

commandKeyPressed
        "Answer whether the command key on the keyboard is being held down."

        ^mouseButtons anyMask: 64

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Stéphane
Ducasse
Sent: 01 May 2007 2:31 pm
To: The general-purpose Squeak developers list
Subject: Real Slowdown of InputSensor between 3.8 and 3.9


Hi

I was surprised by the slowdown of one of my little applications and  
I messageTalliedThem
wtih exactly the same code on 3.8 and 3.9

Here are the results:

MessageTally spyOn:  [ | bdb |
                        BDBase initialize.
                        BDBase resetBaseNamed: #BD.
                        bdb := BDBase new name: #BD.
                        bdb importMostRecentXML.]






On 38

Time millisecondsToRun: [ | bdb |
                BDBase initialize.
                BDBase resetBaseNamed: #BD.
                bdb := BDBase new name: #BD.
                bdb importMostRecentXML.]  1677


**Leaves**
3.2% {56ms} MultiByteFileStream>>next
3.2% {56ms} MultiByteFileStream>>doConversion
3.0% {52ms} UTF8TextConverter>>nextFromStream:
3.0% {52ms} SmallInteger(Number)>>negative
2.9% {51ms} MultiByteFileStream(StandardFileStream)>>basicNext
2.9% {51ms} SAXDriver(XMLTokenizer)>>next
2.9% {51ms} MultiByteFileStream>>converter
2.6% {45ms} ByteSymbol class(String class)>>stringHash:initialHash: 2.5%
{44ms} MultiByteFileStream>>wantsLineEndConversion
2.1% {37ms} MultiByteFileStream(StandardFileStream)>>isBinary

on 39

- 21243 tallies, 21304 msec.

**Tree**
100.0% {21304ms} BDBase>>importMostRecentXML
   99.8% {21261ms} BDBase>>importXMLFromFileName:
     99.8% {21261ms} BDXMLImporter>>importFileNamed:
       99.8% {21261ms} BDXMLImporter>>importStream:
         96.5% {20558ms} BDXMLImporter>>importXMLDoc:
           |89.2% {19003ms} EventSensor(InputSensor)>>shiftPressed
           |  |89.2% {19003ms} EventSensor>>primMouseButtons
           |  |  89.2% {19003ms} EventSensor>>wait2ms
           |  |    89.1% {18982ms} Delay>>wait
           |  |      89.1% {18982ms} primitives
           |7.3% {1555ms} BDXMLImporter>>importBD:
         3.3% {703ms} XMLDOMParser class>>parseDocumentFrom:
           3.3% {703ms} XMLDOMParser class(SAXHandler class)
 >>parseDocumentFrom:
             3.3% {703ms} XMLDOMParser(SAXHandler)>>parseDocument
               3.3% {703ms} SAXDriver(XMLTokenizer)>>nextEntity
                 3.2% {682ms} SAXDriver(XMLTokenizer)>>nextNode
                   3.2% {682ms} SAXDriver(XMLTokenizer)>>nextTag
                     2.7% {575ms} SAXDriver(XMLTokenizer)
 >>nextAttributeInto:namespaces:
**Leaves**
89.1% {18982ms} Delay>>wait

**Memory**
        old +4,748,696 bytes
        young -3,868,600 bytes
        used +880,096 bytes
        free +2,512,576 bytes

**GCs**
        full 1 totalling 83ms (0.0% uptime), avg 83.0ms
        incr 541 totalling 200ms (1.0% uptime), avg 0.0ms
        tenures 25 (avg 21 GCs/tenure)
        root table 0 overflows

Time millisecondsToRun: [ | bdb |
                        BDBase initialize.
                        BDBase resetBaseNamed: #BD.
                        bdb := BDBase new name: #BD.
                        bdb importMostRecentXML.] 21182


So it seems that some logic were changed in the inputSensor. When I  
commented InputSensor default shiftPressed ifTrue: [self halt.]. in  
the import method

importXMLDoc: aXMLDoc

        aXMLDoc elements first elements do:
                [:each | Transcript show: '.'. "InputSensor default
shiftPressed  
ifTrue: [self halt.]."
                                self importBD: each].

Now my benchmarck give me.
Time millisecondsToRun: [ | bdb |
                        BDBase initialize.
                        BDBase resetBaseNamed: #BD.
                        bdb := BDBase new name: #BD.
                        bdb importMostRecentXML.] 1643

I thought that it is worth to share.

Stef





Reply | Threaded
Open this post in threaded view
|

Re: Real Slowdown of InputSensor between 3.8 and 3.9

johnmci
In reply to this post by Stéphane Ducasse-3

On May 1, 2007, at 6:31 AM, Stéphane Ducasse wrote:

>           |  |  89.2% {19003ms} EventSensor>>wait2ms
>           |  |    89.1% {18982ms} Delay>>wait


Ok that is a change I submitted oh back in 2005,  
EventSensorDelayOnHyperPolling

EventSensor>>peekButtons
EventSensor>>peekPosition
EventSensor>>primKbdNext
EventSensor>>primKbdPeek
EventSensor>>primMouseButtons
EventSensor>>primMousePt


The original issue was that in the browser when you moved the cursor  
between window panes the
logic that is responsible for setting the resize pane cursor and  
deciding if the mouse was down would
loop and call primMouseButtons and primMousePt. Under certain  
conditions it would grab the mouse so to speak
and run 100,000 of primMousePt calls, however that would prevent the  
image  from actually servicing any
real mouse movements thus decoupling the squeak mouse location from  
the hardware mouse location

However as you noticed this has a side effect when your code assumes  
looking for the state of the modifier keys
takes 0 milliseconds. Gary's solution could be considered but you  
need to see who the callers are to avoid excessive polling,
perhaps you'll need a call to look and wait the 2ms to avoid  
excessive polling but make that an explicit request and use on
an as needed basis.

Also Gary's code only considers the cached state of the button and  
modifiers, without reasking the VM for the information, that
assumes state changes will at some point flow up to the cached value  
as part of the normal EventSensor processing.
Technically that should happen anyway, and I'd guess peformance is  
better than the original code which attempts to ask the
VM for the current sensor state which can be time consuming.


Mmmm I wonder how much Sensor peeking is going on in a 3.9 image and  
how the wait2ms is affecting things?

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===



Reply | Threaded
Open this post in threaded view
|

RE: Real Slowdown of InputSensor between 3.8 and 3.9

Gary Chambers-4
Oh, and I've noticed on the Linux VM, due to the keyboard handling, you can
poll all you like but not pickup the change (unless another key is pressed
at the same time or the mouse moved).

On Win32 the events get pushed in via the semaphore to update the state
anyway.

Would be nice to have it officially sorted. I wonder if the Sophie team
have?


Reply | Threaded
Open this post in threaded view
|

RE: Real Slowdown of InputSensor between 3.8 and 3.9

Gary Chambers-4
Would be nice too if Morph/EventHandler could deal with mouseOver events (no
button down) too. Would save getting the mouse position from the Sensor
directly in, say, a step method!



Reply | Threaded
Open this post in threaded view
|

Re: Real Slowdown of InputSensor between 3.8 and 3.9

Igor Stasenko
hmm.. you have mouseEnter/mouseLeave events.
AFAIK mouseOver is just state between them.

On 01/05/07, Gary Chambers <[hidden email]> wrote:
> Would be nice too if Morph/EventHandler could deal with mouseOver events (no
> button down) too. Would save getting the mouse position from the Sensor
> directly in, say, a step method!
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Real Slowdown of InputSensor between 3.8 and 3.9

Gary Chambers-4
Morph does implement #handleMouseOver: but unlike other events does not pass
to its event handler (the EventHandler doesn't hold state for that kind of
event). Means you have to override in a subclass rather than being able to
hook up more generally via #on:send:to:.

Seems to just be an omission...

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of sig
Sent: 02 May 2007 2:28 am
To: The general-purpose Squeak developers list
Subject: Re: Real Slowdown of InputSensor between 3.8 and 3.9


hmm.. you have mouseEnter/mouseLeave events.
AFAIK mouseOver is just state between them.

On 01/05/07, Gary Chambers <[hidden email]> wrote:
> Would be nice too if Morph/EventHandler could deal with mouseOver
> events (no button down) too. Would save getting the mouse position
> from the Sensor directly in, say, a step method!
>
>
>
>