[sugar] python imports and performance (was Re: #5549 ...)

[Tomeu Vizoso]

Hi,

moving to the list as has little to do with the ticket in question.

http://dev.laptop.org/ticket/5549

> Comment(by mstone):
>
>  This seems like a terrible argument to me because of the categorical
>  imperative: if everyone blindly followed style guidelines without making a
>  conscious assessment of the costs imposed by those guidelines then we'd
>  wind up... where we are today, with Python activities that import 10
>  seconds worth of code before becoming interactive.
>
>  Thus, while you're correct that we should place a high value on following
>  conventions, I happen to think that the 'imports at the top' guideline has
>  been so badly discredited by its effect activity startup time as to be
>  untenable in the presence of python modules which perform arbitrary
>  computation at import time. (We could also decide to refuse to use python
>  modules which perform noticeable computation on import, but that seems
>  more painful to me. What do you think?)

I don't think that you are on crack, but I think that should explain
better where you want to go ;)

Someone submitted a patch with a violation of the style guidelines.
The submitter commented that this violation was made because of
performance considerations. I explained why there was no performance
hit that would justify that deviance from what is expected the sugar
code to look like. What argument are you calling terrible? What has
Kant to do with all this? Who is blindly following anything?

If activities take X seconds to startup because of module-level code,
it has little to do with the imports being at the top or being inline.
The modules are loaded because they are imported before the activity
window is brought up, and that happens because they are actually
needed to perform all the initializations that we want (perhaps
mistakenly) to do during activity startup.

Now I'm a bit angry at Michael and Chris, because they have managed to
drag me again into this old discussion when a little experimentation
would have convinced them instead. Just try to move the imports from
the top to just before being used, and see if there's any advantage in
startup time.

Do you really think that I'm so stupid as to have invested so much
work on the prefork hack just to avoid shuffling some imports around?
In fact, I moved one import to inline when I measured that it actually
made a difference (1 second out of 7):
http://dev.laptop.org/git?p=sugar-base;a=commitdiff;h=cc7bbec111d691c198ef6c9ca761c8f576882d0a

If you can find other modules that are not needed during startup but
are actually slowing activity startup, please send patches. I don't
expect you to have any problem in having them accepted if you show
some evidence of improvements.

And for the record, the right fix from my POV is to only register
names at the module scope, moving all expensive initializations to be
done lazily when things are actually called. Don't know what's the
opinion in the python community about this, though.

Regards,

Tomeu