[Sugar-devel] Report about performance hackaton

[Manuel Quiñones]

Excellent resume Gonzalo!

I have added yours and my thoughts in a feature page:
http://wiki.sugarlabs.org/go/Features/Optimize_TreeViews

I think this can be handled as a feature.

2014-02-23 23:40 GMT-03:00 Gonzalo Odiard <godiard at sugarlabs.org>:
> 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].

And worst, it was racy.  So you can crash Sugar if you move the mouse
over the Journal icons for a while.

>
> * 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
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
.. manuq ..