#2773 HIGH Trial-3: Some sugar modules are running code on import causing hard to debug performance issues

[Zarro Boogs per Child]

#2773: Some sugar modules are running code on import causing hard to debug
performance issues
---------------------+------------------------------------------------------
  Reporter:  J5      |       Owner:  tomeu  
      Type:  defect  |      Status:  new    
  Priority:  high    |   Milestone:  Trial-3
 Component:  sugar   |     Version:         
Resolution:          |    Keywords:  review+
  Verified:  0       |  
---------------------+------------------------------------------------------
Comment (by smcv):

 > presence/presenceservice.py - calls logging.getLogger()

 This is conventional use of the standard Python logging infrastructure.
 You could delay creating the logger until a class that can use it is
 __init__'d (using "global logger; if logger is None: logger =
 logging.getLogger()") but I think that's complicating the code for no good
 reason.

 > Well, I'm more concerned about having the dbus connection open all time.
 Perhaps we should do the Store object you mention and have the dbus
 connection closed when Store is dereferenced.

 Are you talking about the connection to the session bus (which all OLPC
 things use), or about the ProxyObject obtained via Bus.get_object()?

 The proxy object is not a "connection" which is "open". It's an API
 abstraction in dbus-python whose only interaction with actual D-Bus
 messages is to call Introspect() when it's instantiated. Once it's been
 created, it costs you a small amount of memory, and what you get for that
 cost is not having to call Introspect() again. It doesn't generate
 spontaneous bus traffic or anything like that - in particular, you don't
 get woken up by broadcast signals unless you ask for them with
 ProxyObject.connect_to_signal() or Bus.add_signal_receiver().

 > Also, we should reopen the dbus connection if the datastore process
 dies, so it will relaunched by the session bus.

 If this is what you want, you can watch NameOwnerChanged using
 Bus.watch_name_owner(), or use a proxy created with
 follow_name_owner_changes=True.

 follow_name_owner_changes=True is only appropriate if the Datastore's
 D-Bus API is stateless - if there is no transient state shared between the
 client wrappers and the service, i.e. all state is stored in the database
 so will be consistent in the new instance, then you could probably get
 away with it.

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