#3019 HIGH Trial-3: PATCH: Optimize get_activities by making it async

[Zarro Boogs per Child]

#3019: PATCH: Optimize get_activities by making it async
---------------------+------------------------------------------------------
  Reporter:  J5      |       Owner:  tomeu               
      Type:  defect  |      Status:  new                 
  Priority:  high    |   Milestone:  Trial-3             
 Component:  sugar   |     Version:                      
Resolution:          |    Keywords:  optimization review?
  Verified:  0       |  
---------------------+------------------------------------------------------
Comment (by J5):

 The code in the wrappers is more complex for flexibility sake (though the
 whole thing is mostly boilerplate code) but the code in the clients simply
 break up the sync call into a callback.  All operations over D-Bus are by
 definition networked as they go over sockets.  There is no promise that a
 call will return in constant time and mostly depends on who is talking to
 the service at what time.  Making the calls async guards against this as
 well as guarding against possible changes to the remote method itself.
 This is almost the same as the transition from top down programming to an
 event based model in GUI systems.  Sure it gets more complex but if you
 don't think about blocking issues you are going to end up with a program
 that performs non-optimally which is amplified even more by our processor.

 BTW while startup of processes results in the largest chunk of reclaimed
 idle time, first call always has extra overhead associated with getting
 Introspect information back.  If your first call from a proxy is non-
 blocking then introspect stays non-blocking.  If first call is blocking
 and introspect has not returned, we first block on introspect and then
 make the the blocking call.

 As for startup, it looks like the python Reflection API may be the
 culprit.  I need to do profiling there too.  My next steps are to profile
 imports and also our loops.

 I'll try hotspot but the last time I used it loading the data it produced
 crashed python.  That was when we were based off of 2.4 and FC6 though.

-- 
Ticket URL: <https://dev.laptop.org/ticket/3019#comment:11>
One Laptop Per Child <http://laptop.org/>