> 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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel