[Sugar-devel] Report about performance hackaton

[Alan Jhonn Aguiar Schwyn]

Good job!

Date: Sun, 23 Feb 2014 23:40:51 -0300
From: godiard at sugarlabs.org
To: manuq at laptop.org; sugar-devel at lists.sugarlabs.org
Subject: [Sugar-devel] Report about performance hackaton

The last Thursday and Friday, manuq and I worked together to try to find the source of a few performance issues in Sugar.
In particular, we worked in the treeviews, for the activities list
and the Journal.
We did many, many tests, and learned a few tricks, here is a first summary.The patches are not ready to push upstream, but we will continue working on this

in the next weeks. You can look at the branches here [1] and [2]
Findings:
* We did test programs to test the treeview and profile it doing:

python -m cProfile test_treeview.py > profile.txt

This was very useful. We did tests to profile the scroll and to start the journal as a newapplication in a terminal. [3]

* The source of the performance issues in the treeview is the CellRendererIcon,a treeview without it works ok.
* The CellRendererIcon do a lot of unneeded work, the render method can be optimized,
caching values.
* The CellRendererIcon is connected to many signals, just detaching them while scrollingsolves part of the problem. To do it, we implemented a ScrollingDetector class.

* The CellRendererIcon is not a widget, then, do not receive events when the mouse enter or leaves, and all the logic in the CellRendererInvoker is more complex than should be. Worst, we had 6 different CellRendererIcons in the 
Journal, then we simplified (and solved issues) implementing a TreeViewInvoker.The TreeView knows where is every cell. While is much more simple and responsive,implementation is not finished yet.  

* The ObjectPalettes was created in the mouse enter callback, then if a user movedthe mouse cursor over the activity icons., many palettes were created, and that was expensive [4].

* This changes make the activity list work really fast. The Journal no longer freezeif a user move the mouse over the activity icons, but the scroll is still slowing at one point.
First we thought that was because of the datastore, but we found the journal request first 30 records, and later add 10 records more, and caches the last 50. Trying with a journalwith less than 30 records we still see a moment when the Journal scroll jumps,
but the datastore is not working.  We find a suspicious method "send_message_with_reply_and_block" doing the profiling, but we didn't found where is used of is responsible of the problem.

As you can see, this is only a start. We will prepare a wiki page with the informationwhen is more clean, but wanted to share our findings, with the community.Was really great work together in this issue in the same place,
I wonder if we can find a way to organize virtual hackatons by topics like this.
Regards,
-- 

[1] https://github.com/manuq/sugar-toolkit-gtk3/commits/scrollingdetector
[2] https://github.com/manuq/sugar/commits/treeviews-optimizations[3] http://blog.ludovf.net/python-profiling-cprofile/
[4] http://bugs.sugarlabs.org/ticket/4343
Gonzalo Odiard

SugarLabs - Learning Software for children




_______________________________________________
Sugar-devel mailing list
Sugar-devel at lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140224/8c036675/attachment.html>