Jerome Laheurte | 10 Aug 15:28
Favicon

Sloooooooow


I noticed something strange. When I run TaskCoach from the Release0_70 
branch, it works fine. When I run it from rev. 1196 (before my merge) 
from trunk, fine. When I run it from HEAD trunk, it's slow as hell and 
takes up to 80% CPU doing nothing.

Does anybody notice the same thing ? If so, I probably did something 
very wrong when merging.

Cheers
Jérôme
------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/taskcoach-dev/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:taskcoach-dev-digest@... 
    mailto:taskcoach-dev-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
(Continue reading)

Jerome Laheurte | 10 Aug 16:03
Favicon

Re: Sloooooooow

On Sun, 10 Aug 2008, Jerome Laheurte wrote:

> I noticed something strange. When I run TaskCoach from the Release0_70
> branch, it works fine. When I run it from rev. 1196 (before my merge)
> from trunk, fine. When I run it from HEAD trunk, it's slow as hell and
> takes up to 80% CPU doing nothing.
>
> Does anybody notice the same thing ? If so, I probably did something
> very wrong when merging.

Okay, this seems to be related to the fact I run Compiz Fusion; when 
starting KDE in "regular" kwin mode, it's OK.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/taskcoach-dev/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/taskcoach-dev/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:taskcoach-dev-digest@... 
    mailto:taskcoach-dev-fullfeatured@...
(Continue reading)

Frank Niessink | 10 Aug 16:50

Re: Sloooooooow

Hi Jerome,

2008/8/10 Jerome Laheurte <fraca7@...>:
>
> I noticed something strange. When I run TaskCoach from the Release0_70
> branch, it works fine. When I run it from rev. 1196 (before my merge)
> from trunk, fine. When I run it from HEAD trunk, it's slow as hell and
> takes up to 80% CPU doing nothing.
>
> Does anybody notice the same thing ? If so, I probably did something
> very wrong when merging.

Yeah, I noticed it too. It's probably the EffortViewerColumnPopupMenu
that's reconstructed on every wx.EVT_UI_UPDATE (basically every time
you open a menu, hover over a button, etc.). From this comment (which
is yours I think?):

    # Since the aggregation can change in the viewer's lifetime and
    # the UICommands depend on it, this is getColumnUICommands instead
    # of createColumnUICommands.

I conclude we do need to cache the ColumnUICommands. I'm working on it.

Cheers, Frank

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
(Continue reading)

Frank Niessink | 10 Aug 17:06

Re: Sloooooooow

Hi,

2008/8/10 Frank Niessink <frank@...>:

> Yeah, I noticed it too. It's probably the EffortViewerColumnPopupMenu
> that's reconstructed on every wx.EVT_UI_UPDATE (basically every time
> you open a menu, hover over a button, etc.). From this comment (which
> is yours I think?):
>
>    # Since the aggregation can change in the viewer's lifetime and
>    # the UICommands depend on it, this is getColumnUICommands instead
>    # of createColumnUICommands.
>
> I conclude we do need to cache the ColumnUICommands. I'm working on it.

I was warm, but not exactly right. It was this code in menu.py that
was executing too often:

class DynamicMenuThatGetsUICommandsFromViewer(DynamicMenu):
    ...
    def updateMenuItems(self):
        newCommands = self.getUICommands()
        if newCommands != self._uiCommands:
            self.clearMenu()
            self.fillMenu(newCommands)
            self._uiCommands = newCommands

It turned out the newCommands was never equal to self._uiCommands,
since EffortViewer.getUICommands would create a new list every time it
was called. I added a __eq__ method to the UICommand class so that two
(Continue reading)

Jerome Laheurte | 10 Aug 18:01
Favicon

Re: Sloooooooow

On Sun, 10 Aug 2008, Frank Niessink wrote:

> Hi,
>
> 2008/8/10 Frank Niessink <frank@...>:
>
>> Yeah, I noticed it too. It's probably the EffortViewerColumnPopupMenu
>> that's reconstructed on every wx.EVT_UI_UPDATE (basically every time
>> you open a menu, hover over a button, etc.). From this comment (which
>> is yours I think?):
>>
>>    # Since the aggregation can change in the viewer's lifetime and
>>    # the UICommands depend on it, this is getColumnUICommands instead
>>    # of createColumnUICommands.
>>
>> I conclude we do need to cache the ColumnUICommands. I'm working on it.
>
> I was warm, but not exactly right. It was this code in menu.py that
> was executing too often:
>
> class DynamicMenuThatGetsUICommandsFromViewer(DynamicMenu):
>    ...
>    def updateMenuItems(self):
>        newCommands = self.getUICommands()
>        if newCommands != self._uiCommands:
>            self.clearMenu()
>            self.fillMenu(newCommands)
>            self._uiCommands = newCommands
>
> It turned out the newCommands was never equal to self._uiCommands,
(Continue reading)


Gmane