Speedup the Sugar Shell with Psyco, Part II

Yesterday I was playing with Psyco trying to get a little bit faster Sugar shell, today I’ve done a couple of tests using Sysprof to watch the behavior of a normal sugar v/s a modified one using Psyco, so here we go:



Machine: XO-B4
Build: Joyride 227

Library/Function Normal Sugar Sugar + Psyco
/lib/libglib-2.0.so.0.1200.13 86.26 % 63.06 %
/usr/lib/libgtk-11-2.0.so.0.1000.14 86.17 % 65.80 %
/usr/lib/libpython2.5.so.1.0 84.09 % 85.75 %
/usr/bin/python 82.21 % 55.46 %
/usr/lib/python2.5/site-packages/gtk-2.0/gtk/_gtk.so 82.11 % 60.57 %
__libc_start_main 81.62 % 62.35 %
/lib/libgobject-2.0.so.0.1200.13 75.20 % 63.06 %
/usr/lib/libhippocanvas-1.so.0.0.0 65.81 % 76.48 %
in kernel 3.95 % 3.92 %

The optimized files were:

  • sugar/util.py
  • shell/view/Shell.py
  • shell/view/pulsingicon.py
  • graphics/spreadlayout.py
  • graphics/icon.py
  • graphics/animation.py
  • graphics/palette.py
  • graphics/palettegroup.py
  • graphics/toolbutton.py

the methods/functions binded by Psyco were the most heavier profiled, the resources used in this performance are just some CPU time at the beginning and 50KB of extra memory… it’s time to send patches? >:)

Speedup the Sugar Shell with Psyco

Today I’ve been doing a lot of test to my XO-B4 machine, I was looking for different ways in order to speedup the Sugar Shell, and I found an interesting project called Psyco:

“In short: run your existing Python software much faster, with no change in your source. Think of Psyco as a kind of just-in-time (JIT) compiler, a little bit like what exists for other languages, that emit machine code on the fly instead of interpreting your Python program step by step. The difference with the traditional approach to JIT compilers is that Psyco writes several version of the same blocks (a block is a bit of a function), which are optimized by being specialized to some kinds of variables (a “kind” can mean a type, but it is more general). The result is that your unmodified Python programs run faster.”

Testing Joyride 227, I decided to install Psyco and do some benchmark with it to the Sugar Shell using the profile() method provided. Psyco gives to every method/function/call an “importance level” so I got a lot of interesting data about which calls are more heavier than others, by default the profile system shows the top ten heavy calls:


01:08:31 AM.77 ______
#1 | 5.7 %| do_paint_below_children .../graphics/icon.py:448
#2 | 5.3 %| ...r/bin/sugar-shell:18
#3 | 5.2 %| _get_cache_key .../graphics/icon.py:93
#4 | 5.0 %| get_surface .../graphics/icon.py:201
#5 | 5.0 %| _get_xo_color .../graphics/icon.py:187
#6 | 4.7 %| _parse_string ...aphics/xocolor.py:203
#7 | 3.8 %| do_set_property .../graphics/icon.py:392
#8 | 3.5 %| _pulse_cb ...ctivitiesdonut.py:148
#9 | 3.4 %| __init__ ...aphics/xocolor.py:219
#10 | 2.8 %| buildfncache ...psyco/profiler.py:66
01:08:33 AM.66 ______
#1 | 7.5 %| do_paint_below_children .../graphics/icon.py:448
#2 | 6.1 %| _get_xo_color .../graphics/icon.py:187
#3 | 5.2 %| __init__ ...aphics/xocolor.py:219
#4 | 5.0 %| ...r/bin/sugar-shell:18
#5 | 5.0 %| get_surface .../graphics/icon.py:201
#6 | 4.4 %| _get_cache_key .../graphics/icon.py:93
#7 | 4.2 %| _pulse_cb ...ctivitiesdonut.py:148
#8 | 4.1 %| _parse_string ...aphics/xocolor.py:203
#9 | 2.8 %| do_set_property .../graphics/icon.py:392

Psyco doesn’t try to improve the performance of all your software, you have to tell it which calls you want to improve, obviously you want to decrease the importance level of the ones that are heavier. For this, Psyco provides a pysco.bind() method where you decide which one to improve. I got good results, the importance level of the calls chosen has decreased and I can see that Sugar is a little bit faster than before but… it takes a little more time to start and it takes more memory than usual. I’ll continue doing more tests to get real values of this optimization.

OLPC: Developer Console v/s Developer Environment

In early versions of OLPC builds, there’s was a tool called Developer Console, the main idea of this application was to have a GUI where’s possible to have a CPU usage graphic, logviewer, terminal, memory analysis, etc. But in the meaning time, developer console was trying to have a lot of features, but every feature means to be watching something in the XO and it start to consume a lot of resources :/ . So talking with Marco and Eben we decide to change this current model by a Developer Environment, which is composed by three Sugar activities:

  • Analyze: Get resources usage by the XO
  • Terminal: A graphical terminal/shell
  • Logviewer: A log viewer application

Some people still miss the old developer console, every tool has advantages and disadvantages, in my personal case is more confortable to have separated tasks that all together in an application that eat a lot of memory and do a lot of I/O.

At this moment I’m working in a XO-Monitor application, I hope to publish about it this weekend 😉

Open Source 2007 event

Between Nov 21th to 23th, the Open Source 2007event took place in
Chile, it was organized by Inacap Valparaiso.
The audience was from students to business people, a lot of speeches
were made and practical classes about different pieces of software,
every event is a good opportunity to meet new people and enjoy to talk
about open source softwares and related projects. Lot of speakers were
invited to talk about something interesting, I gave a speech about the
OLPC project and I decide to give a second speech about the Summer Of
Code
program in order to promote and motivate to the students and let
them know about the program and how to get involved in the open source
world.

A lot of people attend the speech, at the beginning nobody knows what
it’s exactly ‘Summer of code’, they all just know that it’s something
related to Google, I talked about the ‘Hacker culture’, some history
about the open source software and Google.
They started to feel so exciting with the idea to get involved in a OS
project and much more if is through Google.
A lot of directors of the university agree that if someone of their
students become a GSoC student, they can accept that job as a
practical required in they program career. They asked me a lot of
interesting questions, so I hope that next year more Chileans can send
their applications and get a good opportunity to learn and
contribute…