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