Did wx get MUCH slower between 2.4 and 2.6+?

I'd move to, but, regrettably, I'm stuck at 2.6.3.3, as I require
a py2.3.5 build, and that was the last official one for that
release of Python...
/Will

Kevin Ollivier wrote:

···

Hi Will,

At least in 2.8, I see wx.ComboBox has an AppendItems(list) method,
could you try that and see if it helps?

Regards,

Kevin

On Dec 13, 2006, at 11:20 AM, Will Sadkin wrote:

Ok,

I've tracked down at least one of the major slowdowns...

I have a set of auxillary library functions, to compensate
for some long standing deficiencies in wx. One of them is
a function to set the contents of the combobox or a listbox
to a given list of options. Because I can't just say
wx.Combobox.SetList(list), long ago, I wrote:

# helper functions to get around wx.Python deficiencies:
# no .S/GetList() for wx.ComboBox, wx.ListBox

def setList(control, list):
    control.Clear()
    for element in list:
        control.Append(element)

def getList(control):
    list =
    for i in range(control.GetCount()):
        list.append(control.GetString(i))
    return list

It appears that using the 1st of these now takes ~235ms
to load 97 strings into a on a 2.6.3.3 wx.Combobox dropdown,
whereas with 2.4, this takes ~16ms. On many of these
screens I have lots of comboboxes, so multiplied, this
makes a big difference...

Is there anything I can do about this? Is there
an alternative method that's faster?

/Will

Kevin Ollivier wrote:

Hi Will,

On Dec 12, 2006, at 6:27 PM, Will Sadkin wrote:

Josiah Carlson wrote:

Will Sadkin <WSadkin@Parlancecorp.com> wrote:

In the old version of the code, these operations were virtually
instantaneous; with the new version, you can actually watch the
individual controls change, and it can take several seconds (!)
to reload them all. I've tried adding .Freeze() and .Thaw()
calls in the hope that this would make it faster, but this only
makes the change appear to hesitate for the same interval, and
then update all at once. The lag is so noticeable that I feel
like there ought to be wait cursor, but I can't help but feel
that loading up 20-40 controls with values *should NOT* take this
long! (and didn't before...)

I don't remember noticing a slowdown of that magnitude, or really
any slowdown at all. Are you sure it is wxPython? Perhaps it
could be some portion of your application that is doing some
operation that is taking a long time to execute.

Yep, I'm sure... I just made the minimal changes required to
make my 2.6 application work again with 2.4, this time retaining
the wx. syntax everywhere but where absolutely necessary,
and then swapped out the wx 2.6 library with 2.4. With 2.4,
the updates are acceptably fast, but with 2.6, they aren't,
by a long shot...

Are you seeing this on multiple platforms, or one in particular?
Also, what kinds of controls are you updating, and are you doing
anything in threads? On platforms I support, I see no performance
degradation in 2.6 so I somewhat doubt this is an issue with 2.6
just being slower in general. What's I think more likely is that
there's a wx bug that your code is causing to surface.

As for ways to help track this down, I'd first recommend trying 2.8
and seeing if it still has the same issue. If so, I'd suggest either
posting some code showing the problem here (if you can), or adding
print statements to various points in the control updating code to
see precisely where the code starts to become slow, and then speeds
up again.

Regards,

Kevin

?
/Will

--------------------------------------------------------------------
- To unsubscribe, e-mail:
wxPython-users-unsubscribe@lists.wxwidgets.org For additional
commands, e-mail: wxPython-users- help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-
unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail:
wxPython-users-unsubscribe@lists.wxwidgets.org For additional
commands, e-mail: wxPython-users- help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org

Hi Will,

I'd move to, but, regrettably, I'm stuck at 2.6.3.3, as I require
a py2.3.5 build, and that was the last official one for that
release of Python...

I mentioned it as I have a feeling AppendItems is in 2.6.3.3 too, I just can't confirm right now. If you want to check, you can do something like:

import wx
if "AppendItems" in dir(wx.ComboBox):
  print "Yay!"

Regards,

Kevin

···

On Dec 13, 2006, at 12:24 PM, Will Sadkin wrote:

/Will

Kevin Ollivier wrote:

Hi Will,

At least in 2.8, I see wx.ComboBox has an AppendItems(list) method,
could you try that and see if it helps?

Regards,

Kevin

On Dec 13, 2006, at 11:20 AM, Will Sadkin wrote:

Ok,

I've tracked down at least one of the major slowdowns...

I have a set of auxillary library functions, to compensate
for some long standing deficiencies in wx. One of them is
a function to set the contents of the combobox or a listbox
to a given list of options. Because I can't just say
wx.Combobox.SetList(list), long ago, I wrote:

# helper functions to get around wx.Python deficiencies:
# no .S/GetList() for wx.ComboBox, wx.ListBox

def setList(control, list):
    control.Clear()
    for element in list:
        control.Append(element)

def getList(control):
    list =
    for i in range(control.GetCount()):
        list.append(control.GetString(i))
    return list

It appears that using the 1st of these now takes ~235ms
to load 97 strings into a on a 2.6.3.3 wx.Combobox dropdown,
whereas with 2.4, this takes ~16ms. On many of these
screens I have lots of comboboxes, so multiplied, this
makes a big difference...

Is there anything I can do about this? Is there
an alternative method that's faster?

/Will

Kevin Ollivier wrote:

Hi Will,

On Dec 12, 2006, at 6:27 PM, Will Sadkin wrote:

Josiah Carlson wrote:

Will Sadkin <WSadkin@Parlancecorp.com> wrote:

In the old version of the code, these operations were virtually
instantaneous; with the new version, you can actually watch the
individual controls change, and it can take several seconds (!)
to reload them all. I've tried adding .Freeze() and .Thaw()
calls in the hope that this would make it faster, but this only
makes the change appear to hesitate for the same interval, and
then update all at once. The lag is so noticeable that I feel
like there ought to be wait cursor, but I can't help but feel
that loading up 20-40 controls with values *should NOT* take this
long! (and didn't before...)

I don't remember noticing a slowdown of that magnitude, or really
any slowdown at all. Are you sure it is wxPython? Perhaps it
could be some portion of your application that is doing some
operation that is taking a long time to execute.

Yep, I'm sure... I just made the minimal changes required to
make my 2.6 application work again with 2.4, this time retaining
the wx. syntax everywhere but where absolutely necessary,
and then swapped out the wx 2.6 library with 2.4. With 2.4,
the updates are acceptably fast, but with 2.6, they aren't,
by a long shot...

Are you seeing this on multiple platforms, or one in particular?
Also, what kinds of controls are you updating, and are you doing
anything in threads? On platforms I support, I see no performance
degradation in 2.6 so I somewhat doubt this is an issue with 2.6
just being slower in general. What's I think more likely is that
there's a wx bug that your code is causing to surface.

As for ways to help track this down, I'd first recommend trying 2.8
and seeing if it still has the same issue. If so, I'd suggest either
posting some code showing the problem here (if you can), or adding
print statements to various points in the control updating code to
see precisely where the code starts to become slow, and then speeds
up again.

Regards,

Kevin

?
/Will

--------------------------------------------------------------------
- To unsubscribe, e-mail:
wxPython-users-unsubscribe@lists.wxwidgets.org For additional
commands, e-mail: wxPython-users- help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-
unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail:
wxPython-users-unsubscribe@lists.wxwidgets.org For additional
commands, e-mail: wxPython-users- help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

If you use the ANSI wxPython and use the StyledTextCtrl, consider using
2.6.3.2, as 2.6.3.3 ANSI stc has a copy/paste bug on some platforms.

- Josiah

···

Will Sadkin <WSadkin@Parlancecorp.com> wrote:

I'd move to, but, regrettably, I'm stuck at 2.6.3.3, as I require
a py2.3.5 build, and that was the last official one for that
release of Python...