Something I forgot to mention is that when testing activity startup you really need to clean the kernel memory cache before each run, or you will get inconsistent data.
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" On 9 March 2014 18:46, Daniel Narvaez <dwnarv...@gmail.com> wrote: > On 9 March 2014 17:53, Sebastian Silva <sebast...@fuentelibre.org> wrote: > >> Hi dear Sugar developers. >> We have participated in the deployment in Peru of Sugar 0.94 (classic) >> for XO1 and XO1.5. It will be ongoing in 2014 and hopefully we will tighten >> the feedback circle and work closer with upstream (master). >> Now we as a team are working in Colombia with XO1.75 and again, the issue >> of performance creeps in, and they are interested in downgrading to Sugar >> 0.94 (classic). >> "that way madness lies", if we stay without updating, we break cohesion. >> It would be best if we could all just work on the same basis. >> >> For us to base our work on 0.101+ (new) Sugar, we have to make sure we >> have solved the performance issues plaguing (new) Sugar and/or OLPC/OS 13.x. >> > > Which OLPC version are you comparing with? In the rest of the answer I'll > call that X.x :) > > >> >> For this I need your advice. >> >> *How do I setup an identical environment for (classic) 0.94 Sugar and >> (new) 0.101+ Sugar? Can I use sugar-build for this, or something else...?* >> > > On which hardware and on which distribution? > > Anyway it's probably not going to be trivial. So let me suggest an easier > first step. You could test 0.94 activities on the top of OLPC 13.x. If they > perform the same as OLPC X.x then we know the issue is the gtk3 toolkit (no > change was made to the gtk2 toolkit). If they are bad as stock 13.x > activities, then we will know it's something in the system. If it's > something in the middle we will have to come up with a more complicated > strategy. But I think the data we get from this initial testing will be > useful to figure out that strategy. > > >> >> *How do I profile the session (CPU usage, memory consumption, timing)? * >> > > For memory I would try this > > https://github.com/pixelb/ps_mem > > For CPU top should be fine, but it depends what exactly you want to test. > For timing I usually just print out time.time intervals from the code :) > > >> * Do we have some automated GUI testing? Can I make some?* >> > > See sugar-build/build/tests/shell.py, you could use something like that to > measure startup time I suppose. Anyway you can use the same kind of code to > click around in activities UI etc. > -- Daniel Narvaez
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel