[Sugar-devel] Report about performance hackaton

[Gonzalo Odiard]

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