On Mon, 2006-01-23 at 20:15 +0100, David Nielsen wrote: > man, 23 01 2006 kl. 10:57 -0800, skrev Toshio Kuratomi: > > On Mon, 2006-01-23 at 19:31 +0100, David Nielsen wrote: > > > man, 23 01 2006 kl. 18:59 +0100, skrev Ralf Corsepius: > > > > > > > I guess you have benchmarking code to prove this claim to upstream? ;) > > > > > > Well you're in luck some already did, I found this research paper a > > > while back - I took the liberty of putting it on my website hopefully > > > I'm not in violation of anything by doing so. > > > > > > www.lovesunix.net/spaceoptimization.pdf > > > > > > I hope that provides a bit of usable data, at least we could use the > > > methodology to repeated the test for the FC6 cycle. > > > > Interesting read. The big unanswered question seems to be: how does > > this affect the performance of a running application? Does mozilla take > > longer or shorter amounts of time to run once the application loads? Do > > smaller apps benefit less from the optimizations than larger ones? > > > > Could dogtail be used to give predictable "user input" to GUI > > applications or is the speed variable there as well? > > I assume a clever combination of systemtap and dogtail might could give > us a good automated tool for testing a few common scenerios - we just > need someone clever to write it. > > So who wants a thankless job that's probably both hard and prone to > causing methodology flamewars? It would be great if someone want to have a go at implementing this; both technologies are fun to play with. Note that different people could implement the different halves of it; so one person could do the systemtap half, and another can write the dogtail half. Alas, it's difficult to do fully automated the GUI timing testing. The problem I've run into is that if you run a script at full speed, lots of applications break: you get fun race conditions where a program opens a dialog, but the script manages to edit fields in the dialog before the program sets up the "initial" values in the dialog; normally a user is never that quick. Dogtail gets around this problem by adding a sleep after every action; the duration of the sleep is configurable; I've occasionally tried removing it, but so many scripts break or become unreliable that I prefer to err on the side of reliability: dogtail's main focus has been in testing functionality, rather than performance. What you will be able to see from dogtail is if an application starts taking a lot longer than before to bring up its UI, or to respond to input. So it should be possible to get a coarse estimate of "it's slower", or "it's faster", which could be a useful metric. If anyone wants to take this up, or has further ideas, we might be able to add some kind of performance monitoring mode into dogtail. Ideas? Dave -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
