Re: [dabo-dev] Two questions

Ed Leafe wrote:

> On Mar 15, 2005, at 11:23 AM, Paul McNett wrote:

>>> Second, app launching and form creation seems to have slowed down

>>> considerably lately. You mentioned some sort of profiling code a

>>> while back, but I can't find that message. Can you post it again?

>> I found the message:

> OK, I've tried launching the SimpleFormWithBizobj demo app. It takes

> 13-14 seconds on both my Mac and Linux, and 6-7 seconds on Win2K. Does

> that sound right to you?

Here are my Linux times (time between pressing Enter on the command line

until seeing the GUI):

SimpleFormWithBizobj: 7-8 seconds

appRecipes: 2-3 seconds

SimpleFormWithControls: ~3 seconds

minesweeper: ~4 seconds

SimpleFormWithBizobj seems needs to connect to your MySQL server upon

instantiation, which I assume is the lag for me. appRecipes is the time

till the login form is displayed on top of dFormMain (not too many

objects needed to be instantiated yet). SimpleFormWithControls has a

couple dozen objects instantiated I'd guess. minesweeper has 64 buttons

to instantiate plus the form, panel, etc.

These startup times represent the fastest I've seen on any platform I've

tested on (Windows and Mac are definitely slower, although my Win and

Mac machines are underpowered). I haven't noticed any recent slowdown

like you seem to have. I think (without profiling) that instantiation of

dabo objects is slow, due primarily to the setting of the properties in

the init phase, which in turn is slow primarily because of the

getPropertyList() code which has to iterate all the items in

dir(daboObject) (and there are lots of wx items to iterate over) and run

a test which involves eval() to see if each item is a property or not. I

think that the eval() can get probably get axed by querying the __dict__

directly instead, but I remember trying lots of things to no avail.

Perhaps rolling it all into a list comprehension would make it go faster

as well.

Anyway, we shouldn't be overly concerned with startup time at this

point, but rather with making sure it works, and works correctly. I'd be

concerned that too much optimizing now may screw things up that are

working, and because of our general lack of unit testing we may not

notice the introduced problem right away.

But also, for me, it is fast enough as it stands.