[Sugar-devel] Report about performance hackaton

Gonzalo Odiard godiard at sugarlabs.org
Sun Feb 23 21:40:51 EST 2014

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
in the next weeks. You can look at the branches here [1] and [2]


* 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 new
application in a terminal. [3]

* The source of the performance issues in the treeview is the
a treeview without it works ok.

* The CellRendererIcon do a lot of unneeded work, the render method can be
caching values.

* The CellRendererIcon is connected to many signals, just detaching them
while scrolling
solves part of the problem. To do it, we implemented a ScrollingDetector

* 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
The TreeView knows where is every cell. While is much more simple and
implementation is not finished yet.

* The ObjectPalettes was created in the mouse enter callback, then if a
user moved
the 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 freeze
if 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 journal
with less than 30 records we still see a moment when the Journal scroll
but the datastore is not working.  We find a suspicious method
"send_message_with_reply_and_block" doing the profiling, but we didn't
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
when 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



[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140223/2d7073fd/attachment.html>

More information about the Sugar-devel mailing list