Sugar & XFCE (melting treacle)

[John Gilmore]

> That doesn't change the fact that using the XO is like walking neck deep
> in treacle.  ...  The real problem there is it's
> hard to isolate the slowness, I think largely due to the fact that the
> problems aren't isolated.
> 
> Is there any central repository for information about where the speed is
> going?

Nope.  You could create one in the Wiki trivially, though.

The team has been working so hard to just get the major bugs out of
the XO's features, that it hasn't had much time to work on performance.

Many of the XO's performance problems appear to be caused by system-level
impacts of how local technical choices combine.  For example, using a
compressed filesystem makes it expensive in CPU cyles to page in
executables -- yet the limited RAM and lack of swap space causes a
lot of memory pressure, so the VM throws away read-only executable pages
because it knows it can page them in again later.

If I was working on this, I'd try:

  *  Putting a swap partition on an SD card and seeing what it does
     for performance
  *  Building an un-compressed JFFS2 filesystem (it's trivial with the
     tools used) and seeing what it does for performance
  *  Running "prelink" to avoid dirtying pages for shared libraries
     (reducing memory pressure) and see what it does for performance
  *  Working on glibc and other popular libraries in the XO to reduce
     their dirty memory page footprint (it's huge and doesn't need to be)
  *  Fixing bug #4680 in PyGTK+, which causes every multithreaded Python GTK+
     program to uselessly poll ten times a second.
  *  Replacing Sugar with Gnome, KDE, or other GUIs and seeing what it does for
     performance.

Each of these are independent actions that can probably combine
synergistically.  Each takes different expertise and effort.  And the
hardest effort of all is the "seeing what it does for performance" --
making a test framework that can be used to evaluate proposed
improvements, to see if they really DO improve things.  Tools that
watch /proc/*/smaps would be useful in this -- but also, tools that
just run a standard set of activities and feed them test input, and measure
how long it all takes (and whether the right answers come out!).

(This leaves aside network performance issues -- like what makes it
impossible to run 30 XO's in a room on a mesh channel -- but this
msg is too long already.)

	John