Idle MVC RootProject is very CPU hungry

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

Idle MVC RootProject is very CPU hungry

Stéphane Rollandin
Hello,

I just noticed that the top-level RootProject, when entered, makes the
VM take a lot of CPU (a full core on my system, which amounts to 100%).

I'm on windows 8.1.

Is this expected?

Stef

Reply | Threaded
Open this post in threaded view
|

Re: Idle MVC RootProject is very CPU hungry

David T. Lewis
On Sun, Apr 12, 2020 at 03:42:42PM +0200, St??phane Rollandin wrote:
> Hello,
>
> I just noticed that the top-level RootProject, when entered, makes the
> VM take a lot of CPU (a full core on my system, which amounts to 100%).
>
> I'm on windows 8.1.
>
> Is this expected?
>

No, it is not expected. At least I didn't expect it.

I see the same behavior on Linux. I also tested with a trunk-level V3
image on an interpreter VM, and see the same.

So it is not the VM, and it is not the operating system. It happens in
any MVC project, and I also notice that the CPU usage goes back down
to about 25% if I open anything in the MVC project, such as a workspace
or a browser or even an mouse-click world menu.

It looks like the ScreenController is just looping on fetch more events
with no delays involved, and the activity seems to drop down when there
is something for other controllers to do.

Leaving a workspace open in the root project is a workaround.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: Idle MVC RootProject is very CPU hungry

codefrau
On Sun 12. Apr 2020 at 08:39, David T. Lewis <[hidden email]> wrote:
On Sun, Apr 12, 2020 at 03:42:42PM +0200, St??phane Rollandin wrote:
> Hello,
>
> I just noticed that the top-level RootProject, when entered, makes the
> VM take a lot of CPU (a full core on my system, which amounts to 100%).
>
> I'm on windows 8.1.
>
> Is this expected?
>

No, it is not expected. At least I didn't expect it.

I see the same behavior on Linux. I also tested with a trunk-level V3
image on an interpreter VM, and see the same.

So it is not the VM, and it is not the operating system. It happens in
any MVC project, and I also notice that the CPU usage goes back down
to about 25% if I open anything in the MVC project, such as a workspace
or a browser or even an mouse-click world menu.

It looks like the ScreenController is just looping on fetch more events
with no delays involved, and the activity seems to drop down when there
is something for other controllers to do.

Leaving a workspace open in the root project is a workaround.

We did add delays to the menu loops etc. many years ago. Sounds like ScreenController needs that, too?

Morphic has a main loop that uses the relinquish-cpu primitive. MVC does have many little loops (one in each controller) so it’s not as simple. OTOH, only one of the controllers is active at any time. Potentially the relinquish-cpu logic could be added to all of them to reduce idle CPU load.

Btw, in SqueakJS I did a VM-level hack to reduce load. It detects when the sensor primitives are being called rapidly without any user input. That’s a good indicator for the image to be idle.

- Vanessa -


Reply | Threaded
Open this post in threaded view
|

Re: Idle MVC RootProject is very CPU hungry

timrowledge


> On 2020-04-12, at 8:57 AM, Vanessa Freudenberg <[hidden email]> wrote:
>
>
> We did add delays to the menu loops etc. many years ago. Sounds like ScreenController needs that, too?

Looks like it; I think the problem is that the controlLoop is basically
do I want control
while true
do control stuff
AND only the `do control stuff` has any attempt at yielding etc. So in a plain empty screen we end up with a furious whizzing around of trying to find an active controller, not finding one (because the ScreenController is not active unless a mouse button is pressed) and looping through all that ControlManager stuff that wants to find something, anything, please-I'm-bored, to do.

So maybe  something something, only screencontroller in the list of scheduled controllers, something, interactivityPause, something something?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"!" The strange little noise you make when you can't scream...



Reply | Threaded
Open this post in threaded view
|

Re: Idle MVC RootProject is very CPU hungry

David T. Lewis
On Sun, Apr 12, 2020 at 10:42:01AM -0700, tim Rowledge wrote:

>
>
> > On 2020-04-12, at 8:57 AM, Vanessa Freudenberg <[hidden email]> wrote:
> >
> >
> > We did add delays to the menu loops etc. many years ago. Sounds like ScreenController needs that, too?
>
> Looks like it; I think the problem is that the controlLoop is basically
> do I want control
> while true
> do control stuff
> AND only the `do control stuff` has any attempt at yielding etc. So in a plain empty screen we end up with a furious whizzing around of trying to find an active controller, not finding one (because the ScreenController is not active unless a mouse button is pressed) and looping through all that ControlManager stuff that wants to find something, anything, please-I'm-bored, to do.
>

This seems right. The ScreenController does call interActivityPause in
the controlLoop, but that does not seem to be actually happening when
the screen is blank and there is nothing to do.


> So maybe  something something, only screencontroller in the list of scheduled controllers, something, interactivityPause, something something?

Maybe in ScheduledControllers (the ControlManager instance). If there
are no windows open, then there is only one entry in the list of
scheduledControllers, and I don't think that interactivityPause is getting
called in that case. So as you say maybe the control manager needs
to figure out when there is nothing for it to be doing.

I put a plausible fix in the inbox in ST80-dtl.250.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Idle MVC RootProject is very CPU hungry

Karl Ramberg
David,
That drops the idle cycle down nicely on Windows 10 to 0% and the system still seems responsive.

If I hold a mouse button down it jumps up to around 25% cpu usage again. That seems a little excessive

Best,
Karl



On Sun, Apr 12, 2020 at 9:59 PM David T. Lewis <[hidden email]> wrote:
On Sun, Apr 12, 2020 at 10:42:01AM -0700, tim Rowledge wrote:
>
>
> > On 2020-04-12, at 8:57 AM, Vanessa Freudenberg <[hidden email]> wrote:
> >
> >
> > We did add delays to the menu loops etc. many years ago. Sounds like ScreenController needs that, too?
>
> Looks like it; I think the problem is that the controlLoop is basically
> do I want control
> while true
> do control stuff
> AND only the `do control stuff` has any attempt at yielding etc. So in a plain empty screen we end up with a furious whizzing around of trying to find an active controller, not finding one (because the ScreenController is not active unless a mouse button is pressed) and looping through all that ControlManager stuff that wants to find something, anything, please-I'm-bored, to do.
>

This seems right. The ScreenController does call interActivityPause in
the controlLoop, but that does not seem to be actually happening when
the screen is blank and there is nothing to do.


> So maybe  something something, only screencontroller in the list of scheduled controllers, something, interactivityPause, something something?

Maybe in ScheduledControllers (the ControlManager instance). If there
are no windows open, then there is only one entry in the list of
scheduledControllers, and I don't think that interactivityPause is getting
called in that case. So as you say maybe the control manager needs
to figure out when there is nothing for it to be doing.

I put a plausible fix in the inbox in ST80-dtl.250.

Dave




Reply | Threaded
Open this post in threaded view
|

Re: Idle MVC RootProject is very CPU hungry

David T. Lewis
Thanks Karl,

The overall 25% CPU use in MVC seems to be typical, I see the same on
Linux. I think that MVC still relies quite a bit on keyboard polling, and
that's probably the cause.

I'll wait a day or so before moving ST80-dtl.250 to trunk in case someone
suggests a better approach.

Dave


On Mon, Apr 13, 2020 at 08:51:43AM +0200, karl ramberg wrote:

> David,
> That drops the idle cycle down nicely on Windows 10 to 0% and the system
> still seems responsive.
>
> If I hold a mouse button down it jumps up to around 25% cpu usage again.
> That seems a little excessive
>
> Best,
> Karl
>
>
>
> On Sun, Apr 12, 2020 at 9:59 PM David T. Lewis <[hidden email]> wrote:
>
> > On Sun, Apr 12, 2020 at 10:42:01AM -0700, tim Rowledge wrote:
> > >
> > >
> > > > On 2020-04-12, at 8:57 AM, Vanessa Freudenberg <[hidden email]>
> > wrote:
> > > >
> > > >
> > > > We did add delays to the menu loops etc. many years ago. Sounds like
> > ScreenController needs that, too?
> > >
> > > Looks like it; I think the problem is that the controlLoop is basically
> > > do I want control
> > > while true
> > > do control stuff
> > > AND only the `do control stuff` has any attempt at yielding etc. So in a
> > plain empty screen we end up with a furious whizzing around of trying to
> > find an active controller, not finding one (because the ScreenController is
> > not active unless a mouse button is pressed) and looping through all that
> > ControlManager stuff that wants to find something, anything,
> > please-I'm-bored, to do.
> > >
> >
> > This seems right. The ScreenController does call interActivityPause in
> > the controlLoop, but that does not seem to be actually happening when
> > the screen is blank and there is nothing to do.
> >
> >
> > > So maybe  something something, only screencontroller in the list of
> > scheduled controllers, something, interactivityPause, something something?
> >
> > Maybe in ScheduledControllers (the ControlManager instance). If there
> > are no windows open, then there is only one entry in the list of
> > scheduledControllers, and I don't think that interactivityPause is getting
> > called in that case. So as you say maybe the control manager needs
> > to figure out when there is nothing for it to be doing.
> >
> > I put a plausible fix in the inbox in ST80-dtl.250.
> >
> > Dave
> >
> >
> >

>


Reply | Threaded
Open this post in threaded view
|

Re: Idle MVC RootProject is very CPU hungry

marcel.taeumel
Hi all!

Yes, in MVC, some controllers might have to call #interActivityPause explicitely. Well, there is Controller >> #controlLoop, which should take care of most cases. If you browse the senders of #interActivityPause, you see that other #whileTrue: loops have to do this as well. "while that button is pressed ..." and similar.

If will take a look at ST80-dtl.250.

Best,
Marcel

Am 13.04.2020 15:28:03 schrieb David T. Lewis <[hidden email]>:

Thanks Karl,

The overall 25% CPU use in MVC seems to be typical, I see the same on
Linux. I think that MVC still relies quite a bit on keyboard polling, and
that's probably the cause.

I'll wait a day or so before moving ST80-dtl.250 to trunk in case someone
suggests a better approach.

Dave


On Mon, Apr 13, 2020 at 08:51:43AM +0200, karl ramberg wrote:
> David,
> That drops the idle cycle down nicely on Windows 10 to 0% and the system
> still seems responsive.
>
> If I hold a mouse button down it jumps up to around 25% cpu usage again.
> That seems a little excessive
>
> Best,
> Karl
>
>
>
> On Sun, Apr 12, 2020 at 9:59 PM David T. Lewis wrote:
>
> > On Sun, Apr 12, 2020 at 10:42:01AM -0700, tim Rowledge wrote:
> > >
> > >
> > > > On 2020-04-12, at 8:57 AM, Vanessa Freudenberg
> > wrote:
> > > >
> > > >
> > > > We did add delays to the menu loops etc. many years ago. Sounds like
> > ScreenController needs that, too?
> > >
> > > Looks like it; I think the problem is that the controlLoop is basically
> > > do I want control
> > > while true
> > > do control stuff
> > > AND only the `do control stuff` has any attempt at yielding etc. So in a
> > plain empty screen we end up with a furious whizzing around of trying to
> > find an active controller, not finding one (because the ScreenController is
> > not active unless a mouse button is pressed) and looping through all that
> > ControlManager stuff that wants to find something, anything,
> > please-I'm-bored, to do.
> > >
> >
> > This seems right. The ScreenController does call interActivityPause in
> > the controlLoop, but that does not seem to be actually happening when
> > the screen is blank and there is nothing to do.
> >
> >
> > > So maybe something something, only screencontroller in the list of
> > scheduled controllers, something, interactivityPause, something something?
> >
> > Maybe in ScheduledControllers (the ControlManager instance). If there
> > are no windows open, then there is only one entry in the list of
> > scheduledControllers, and I don't think that interactivityPause is getting
> > called in that case. So as you say maybe the control manager needs
> > to figure out when there is nothing for it to be doing.
> >
> > I put a plausible fix in the inbox in ST80-dtl.250.
> >
> > Dave
> >
> >
> >

>




Reply | Threaded
Open this post in threaded view
|

Re: Idle MVC RootProject is very CPU hungry

marcel.taeumel
The issue is that the ScreenController does not #isControlWanted by default. But it is asked over and over again because it is the last remaining controller in the list of controllers.

I think it would be better to just move #interActivityPause to the condition of that while loop:

controlLoop 
[self interActivityPause. self isControlActive] whileTrue: [
self controlActivity. Processor yield]

Best,
Marcel

Am 15.04.2020 17:14:55 schrieb Marcel Taeumel <[hidden email]>:

Hi all!

Yes, in MVC, some controllers might have to call #interActivityPause explicitely. Well, there is Controller >> #controlLoop, which should take care of most cases. If you browse the senders of #interActivityPause, you see that other #whileTrue: loops have to do this as well. "while that button is pressed ..." and similar.

If will take a look at ST80-dtl.250.

Best,
Marcel

Am 13.04.2020 15:28:03 schrieb David T. Lewis <[hidden email]>:

Thanks Karl,

The overall 25% CPU use in MVC seems to be typical, I see the same on
Linux. I think that MVC still relies quite a bit on keyboard polling, and
that's probably the cause.

I'll wait a day or so before moving ST80-dtl.250 to trunk in case someone
suggests a better approach.

Dave


On Mon, Apr 13, 2020 at 08:51:43AM +0200, karl ramberg wrote:
> David,
> That drops the idle cycle down nicely on Windows 10 to 0% and the system
> still seems responsive.
>
> If I hold a mouse button down it jumps up to around 25% cpu usage again.
> That seems a little excessive
>
> Best,
> Karl
>
>
>
> On Sun, Apr 12, 2020 at 9:59 PM David T. Lewis wrote:
>
> > On Sun, Apr 12, 2020 at 10:42:01AM -0700, tim Rowledge wrote:
> > >
> > >
> > > > On 2020-04-12, at 8:57 AM, Vanessa Freudenberg
> > wrote:
> > > >
> > > >
> > > > We did add delays to the menu loops etc. many years ago. Sounds like
> > ScreenController needs that, too?
> > >
> > > Looks like it; I think the problem is that the controlLoop is basically
> > > do I want control
> > > while true
> > > do control stuff
> > > AND only the `do control stuff` has any attempt at yielding etc. So in a
> > plain empty screen we end up with a furious whizzing around of trying to
> > find an active controller, not finding one (because the ScreenController is
> > not active unless a mouse button is pressed) and looping through all that
> > ControlManager stuff that wants to find something, anything,
> > please-I'm-bored, to do.
> > >
> >
> > This seems right. The ScreenController does call interActivityPause in
> > the controlLoop, but that does not seem to be actually happening when
> > the screen is blank and there is nothing to do.
> >
> >
> > > So maybe something something, only screencontroller in the list of
> > scheduled controllers, something, interactivityPause, something something?
> >
> > Maybe in ScheduledControllers (the ControlManager instance). If there
> > are no windows open, then there is only one entry in the list of
> > scheduledControllers, and I don't think that interactivityPause is getting
> > called in that case. So as you say maybe the control manager needs
> > to figure out when there is nothing for it to be doing.
> >
> > I put a plausible fix in the inbox in ST80-dtl.250.
> >
> > Dave
> >
> >
> >

>




Reply | Threaded
Open this post in threaded view
|

Re: Idle MVC RootProject is very CPU hungry

marcel.taeumel
Hi all.

I fixed some CPU-buring issues for MVC projects in both Trunk and Squeak 5.3. I also moved  ST80-dtl.250 to the treated box.

The reason for changing #controlLoop and not #nextActiveController - as Dave proposed - is that I wanted to fix repeated re-scheduling of controllers regardless of whether it is the ScreenController or not.

That #interActivityPause was not there in Smalltalk-80, or was it?

Best,
Marcel

Am 15.04.2020 17:26:54 schrieb Marcel Taeumel <[hidden email]>:

The issue is that the ScreenController does not #isControlWanted by default. But it is asked over and over again because it is the last remaining controller in the list of controllers.

I think it would be better to just move #interActivityPause to the condition of that while loop:

controlLoop 
[self interActivityPause. self isControlActive] whileTrue: [
self controlActivity. Processor yield]

Best,
Marcel

Am 15.04.2020 17:14:55 schrieb Marcel Taeumel <[hidden email]>:

Hi all!

Yes, in MVC, some controllers might have to call #interActivityPause explicitely. Well, there is Controller >> #controlLoop, which should take care of most cases. If you browse the senders of #interActivityPause, you see that other #whileTrue: loops have to do this as well. "while that button is pressed ..." and similar.

If will take a look at ST80-dtl.250.

Best,
Marcel

Am 13.04.2020 15:28:03 schrieb David T. Lewis <[hidden email]>:

Thanks Karl,

The overall 25% CPU use in MVC seems to be typical, I see the same on
Linux. I think that MVC still relies quite a bit on keyboard polling, and
that's probably the cause.

I'll wait a day or so before moving ST80-dtl.250 to trunk in case someone
suggests a better approach.

Dave


On Mon, Apr 13, 2020 at 08:51:43AM +0200, karl ramberg wrote:

> David,
> That drops the idle cycle down nicely on Windows 10 to 0% and the system
> still seems responsive.
>
> If I hold a mouse button down it jumps up to around 25% cpu usage again.
> That seems a little excessive
>
> Best,
> Karl
>
>
>
> On Sun, Apr 12, 2020 at 9:59 PM David T. Lewis wrote:
>
> > On Sun, Apr 12, 2020 at 10:42:01AM -0700, tim Rowledge wrote:
> > >
> > >
> > > > On 2020-04-12, at 8:57 AM, Vanessa Freudenberg
> > wrote:
> > > >
> > > >
> > > > We did add delays to the menu loops etc. many years ago. Sounds like
> > ScreenController needs that, too?
> > >
> > > Looks like it; I think the problem is that the controlLoop is basically
> > > do I want control
> > > while true
> > > do control stuff
> > > AND only the `do control stuff` has any attempt at yielding etc. So in a
> > plain empty screen we end up with a furious whizzing around of trying to
> > find an active controller, not finding one (because the ScreenController is
> > not active unless a mouse button is pressed) and looping through all that
> > ControlManager stuff that wants to find something, anything,
> > please-I'm-bored, to do.
> > >
> >
> > This seems right. The ScreenController does call interActivityPause in
> > the controlLoop, but that does not seem to be actually happening when
> > the screen is blank and there is nothing to do.
> >
> >
> > > So maybe something something, only screencontroller in the list of
> > scheduled controllers, something, interactivityPause, something something?
> >
> > Maybe in ScheduledControllers (the ControlManager instance). If there
> > are no windows open, then there is only one entry in the list of
> > scheduledControllers, and I don't think that interactivityPause is getting
> > called in that case. So as you say maybe the control manager needs
> > to figure out when there is nothing for it to be doing.
> >
> > I put a plausible fix in the inbox in ST80-dtl.250.
> >
> > Dave
> >
> >
> >

>