First, I tracked down a bug in our datanav Page class when working
with date fields. The class uses the dDateTextBox's getDateTuple()
method to get the year, month and day. The problem is that getDateTuple
uses the date class's GetMonth() method to get its month value, and
GetMonth() returns a zero-indexed value: IOW, it ranges from 0-11, not
from 1-12.
Should we change getDateTuple() to return the one-based month? Should
today's date be returned as (2005, 2, 15) or (2005, 3, 15)?
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?
___/
/
__/
/
____/
Ed Leafe
Come to PyCon!!!! http://www.python.org/pycon/2005/
Ed Leafe wrote:
> First, I tracked down a bug in our datanav Page class when working
> with date fields. The class uses the dDateTextBox's getDateTuple()
> method to get the year, month and day. The problem is that getDateTuple
> uses the date class's GetMonth() method to get its month value, and
> GetMonth() returns a zero-indexed value: IOW, it ranges from 0-11, not
> from 1-12.
Is the day zero-indexed as well?
> Should we change getDateTuple() to return the one-based month?
> Should today's date be returned as (2005, 2, 15) or (2005, 3, 15)?
I'd like to see arguments in favor of zero-based dates. At this point it
only seems sensible to make them 1-based like how the world really works.
> 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 haven't noticed a slowdown, but I'll look at my notes regarding
profiling and post the instructions here.
--
pkm ~ http://paulmcnett.com
On Mar 15, 2005, at 10:18 AM, Paul McNett wrote:
> Is the day zero-indexed as well?
No, it's the actual day.
>> Should we change getDateTuple() to return the one-based month?
>> Should today's date be returned as (2005, 2, 15) or (2005, 3, 15)?
>
> I'd like to see arguments in favor of zero-based dates. At this point
> it only seems sensible to make them 1-based like how the world really
> works.
Well, out of the three values in the tuple, only one is typically
written in character form: the month. If you have:
months = (January, February, ...)
then it certainly makes sense to have the month return the proper index.
___/
/
__/
/
____/
Ed Leafe
Come to PyCon!!!! http://www.python.org/pycon/2005/
Ed Leafe wrote:
> On Mar 15, 2005, at 10:18 AM, Paul McNett wrote:
>
>> Is the day zero-indexed as well?
>
>
> No, it's the actual day.
>
>>> Should we change getDateTuple() to return the one-based month?
>>> Should today's date be returned as (2005, 2, 15) or (2005, 3, 15)?
>>
>>
>> I'd like to see arguments in favor of zero-based dates. At this point
>> it only seems sensible to make them 1-based like how the world really
>> works.
>
>
> Well, out of the three values in the tuple, only one is typically
> written in character form: the month. If you have:
>
> months = (January, February, ...)
>
> then it certainly makes sense to have the month return the proper index.
Very true. We should probably keep the zero-indexing, because that's how
Python does it. When people wonder we can refer them to the Python docs.
However, we should be able to display the proper month number to the
user regardless, no?
--
pkm ~ http://paulmcnett.com
On Mar 15, 2005, at 11:09 AM, Paul McNett wrote:
> Very true. We should probably keep the zero-indexing, because that's
> how Python does it. When people wonder we can refer them to the Python
> docs. However, we should be able to display the proper month number to
> the user regardless, no?
The display works fine. The error was that the Page class was using
the values from getDateTuple() to construct its where clause, and was
entering the zero-based month. I've fixed that already.
___/
/
__/
/
____/
Ed Leafe
Come to PyCon!!!! http://www.python.org/pycon/2005/
Ed Leafe 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:
http://leafe.com/archives/showMsg/237300
--
pkm ~ http://paulmcnett.com
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:
> http://leafe.com/archives/showMsg/237300
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?
___/
/
__/
/
____/
Ed Leafe
Come to PyCon!!!! http://www.python.org/pycon/2005/
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:
>> http://leafe.com/archives/showMsg/237300
>
>
> 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.
--
pkm ~ http://paulmcnett.com
Paul McNett wrote:
> 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
Here are my new times, after my latest commit (revision 928):
SimpleFormWithBizobj: ~4 seconds
appRecipes: < 3 seconds
SimpleFormWithControls: < 3 seconds
minesweeper: ~3 seconds
My timings are very unscientific (counting "1-one thousand...") and
these are single trials. Please check on your machine where you were
seeing longer startup times to begin with: I'm hoping you see
significant improvements.
--
pkm ~ http://paulmcnett.com
On Mar 16, 2005, at 2:43 PM, Paul McNett wrote:
> Anyway, we shouldn't be overly concerned with startup time at this
> point
It's just that I'm working through the sample code that I will be
running at PyCon, and every app startup, even those without database
connections, takes a significant amount of time. After 4 or 5 in a row,
it starts to really feel slow.
I'm not looking for ripping out the guts of Dabo, or shaving off 0.1
sec; I just want to see if we can identify any bottlenecks.
___/
/
__/
/
____/
Ed Leafe
Come to PyCon!!!! http://www.python.org/pycon/2005/