I'm generating dynamic forms, and the gui part of the process is
slow.
My forms looks like that :
- a panel, containing rowcolsizer with 10~15 static texts
- a scrolled panel, with a hbox containing 4~10 rowcolsizers with
5~15 rows with 4 static texts, 3 buttons and 1 textctrl per row.
on a p4 1.8 GHz (linux 2.4, python 2.3.1, wxPython 2.4.1.2), data
retriving from database takes 0.6 sec and gui building takes often
more that 4 sec...
Any idea (or, better, docs) about profiling perfs of wxPython app ?
Is there specifics design patterns ?
Hav eyou tried using the Python profiler?
Or can someone tell it isn't anormal ?
Yes, wxRowColSizer can be slow, but I wouldn't expect it to be this bad... It will be ported to C++ in 2.5 but that won't help you now. Probably the best thing is to either switch to a different layout mechanism or do some profiling in the wxRowColSizer Python code and see if there are ways to improve it.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
compared to other calls, these two are more cpu consuming.
>
> Or can someone tell it isn't anormal ?
Yes, wxRowColSizer can be slow, but I wouldn't expect it to be this
bad... It will be ported to C++ in 2.5 but that won't help you now.
Probably the best thing is to either switch to a different layout
mechanism or do some profiling in the wxRowColSizer Python code and see
if there are ways to improve it.
compared to other calls, these two are more cpu consuming.
If you have some time please see if you can find a way to optimize these two methods. (If you need to use features sepecific to Python 2.2+ then that is okay.) Otherwise I'm not sure when I will be able to get to it.
Yes, wxRowColSizer can be slow, but I wouldn't expect it to be this
bad... It will be ported to C++ in 2.5 but that won't help you now. Probably the best thing is to either switch to a different layout mechanism or do some profiling in the wxRowColSizer Python code and see if there are ways to improve it.