#5538 HIGH Retriag: Every python activity emits errors when starting.

[Zarro Boogs per Child]

#5538: Every python activity emits errors when starting.
---------------------+------------------------------------------------------
  Reporter:  cscott  |       Owner:  marco            
      Type:  defect  |      Status:  new              
  Priority:  high    |   Milestone:  Retriage, Please!
 Component:  sugar   |     Version:                   
Resolution:          |    Keywords:  review?          
  Verified:  0       |  
---------------------+------------------------------------------------------

Comment(by tomeu):

 Replying to [comment:8 cscott]:
 > I will note that the gratuitious use of 'imports only at the top' is one
 of the reasons we have performance problems in sugar.  *Every* activity
 ends up importing *all* of sugar, whether it needs it or not.  Moving rare
 imports down to use sites is critical to recovering common-case
 performance.  This code is no less maintainable -- you *do* use a tool
 such as flymake or pylint to ensure that your variables are defined before
 use, don't you?

 I'm not talking about forgetting to add a import before using it. For me
 it's very important to be able to open a module and see in a glance which
 modules are used within it. Seems that I'm not alone in this belief, as it
 is mentioned in our python coding guidelines:
 http://wiki.laptop.org/go/Python_Style_Guide#Imports .

 The root of the problem for me is not that we are importing a lot of
 things at one time, but the fact that some modules do some computationally
 expensive actions at import time that should be deferred lazily. Until we
 track down all the modules that misbehave in this way and correct them,  I
 agree with moving imports to inner scopes. But, as with all optimizations,
 I think we should first measure in a real usage test case what difference
 it makes to the global picture.

 Measuring how much time takes to import a module in a python shell doesn't
 count to me as a real usage case.

 > My understanding is that the canonical specification of the Update.1
 process is at http://wiki.laptop.org/go/Update.1_process , and it doesn't
 mention 'Retriage, Please!' at all.  If it should, the wiki should be
 updated.

 This is being discussed in the devel mailing list right now.

 > Concrete performance numbers:
 > {{{
 > Pippy 'keep as activity': 8-9s, without patch, and spews errors to the
 output window. 6-7s, with patch.
 > import sugar.activity.activity: 5.3s without patch. 0.85s with patch.
 > import sugar.graphics.icon: 3.35s without patch. 0.76s with patch.
 > import sugar.profile: .25s without patch, and spews an error to the log.
 .11s with patch.
 > }}}

 What involves 'keep as activity'?

 > Yes, it is true that at this point much of the savings can be eaten by
 the next import of some package I haven't touched here which itself
 imports transitively all of sugar.  But unless we start moving chunks of
 time from initialization to use, we will always be saddled with high
 startup times.

 See below for a ticket with measures of user-perceived startup time.

 > I am nominating this bug for Update.1 because it has at least one very
 user-visible effects: it removes spurious (and confusing) messages from
 the console when Pippy 'saves as activity'.  The other developer-visible
 effect is that it fixes the confusing messages in the activity log dealing
 with 'failure to load pubkey', which have confused at least one person
 trying to debug a problem with an activity.  I would be happy to spin a
 smaller patch that addressed just those two issues while leaving the
 lion's share of the performance problems alone, but I believe we must make
 a start at solving our performance problems.

 Yes, I firmly believe it's better to discuss each issue in its own ticket.

 I have already meant to make a start at solving the particular performance
 problem in activity launching:

 https://dev.laptop.org/ticket/5228

-- 
Ticket URL: <http://dev.laptop.org/ticket/5538#comment:9>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system