This should fix issue #235.
Recently ConfigTool has been very slow for me on Ubuntu Linux.
When I run the app there is a 15 second wait before the window is
first displayed. I bisected the problem and found it was tied to
the number of pins in `pinNames`, and ultimately that it was
caused by a slow initializer in wx.Choice() when the choices are
loaded when the widget is created. For some reason, moving the
load after the widget is created is significantly faster. This
change reduces my startup time to just under 4 seconds.
Further speedup could be had by using lazy initialization of the
controls. But the controls are too bound up in the loaded data
to make this simple. Maybe I will attack it later.
There is still a significant delay when closing the window, but I
haven't tracked what causes it. Maybe it is caused just by
destroying all these pin controls.
In the process of making this change, I wanted to simplify the
number of locations that bothered to copy the pinNames list and,
to support lazy loading, to try to keep the same list in all
pinChoice controls. I noticed that all the pinChoice controls
already have the same parameters passed to the addPinChoice
function which makes them redundant and confusing. I removed the
extra initializers and just rely on pinNames as the only list
option in addPinChoice for now. Maybe this flexibility is needed
for some reason later, but I can't see a purpose for it now.
Notes by reviewer Traumflug:
First of all, which "trick"? That's an excellent code
simplification and if this happens to make startup faster (it
does), all the better.
Measured startup & shutdown time here (click window close as soon
as it appears):
Before: With this commit:
real 0m4.222s real 0m3.780s
user 0m3.864s user 0m3.452s
sys 0m0.084s sys 0m0.100s
As the speedup was far more significant on the commit author's
machine, it might be a memory consumption issue (leading to
swapping on a small RAM machine). Linux allows to view this in
/proc/<pid>/status.
Before: Now:
VmPeak: 708360 kB 708372 kB
VmSize: 658916 kB 658756 kB
VmHWM: 73792 kB 73492 kB
VmRSS: 73792 kB 73492 kB
VmData: 402492 kB 402332 kB
Still no obvious indicator, but a 300 kB smaller memory footprint
is certainly nice.
Nico Tonnhofer
Phil Hord
Markus Hitter
Ruslan Popov
jbernardis