RE: GtkPerf data for GTK+ 2.6 vs GTK+ 2.10 vs Maemo-GTK+ 2.6

[<Dirk-Jan Binnema nokia com>]

Hi Benjamin, 

>-----Original Message-----
>From: performance-list-bounces gnome org 
>[mailto:performance-list-bounces gnome org] On Behalf Of ext 
>Benjamin Otte
>Sent: Thursday, August 17, 2006 14:14
>To: cworth cworth org
>Cc: performance-list gnome org
>Subject: Re: GtkPerf data for GTK+ 2.6 vs GTK+ 2.10 vs Maemo-GTK+ 2.6

[....]

>Then I did the usual statistic stuff and didn't include the 
>slowest and fastest 10% of the results. After that the times 
>that got still included differed by around 15%, depending on 
>run and test.
>I then tried to exclude top and bottom 20% which reduced the 
>maximum time difference to around 10%, which I liked even 
>more, so I left it at that.
>So with my patch above the code discards the top and bottom 16 
>results and calculates the average of the resulting 52 runs.
>
>The third thing I did was trying to reduce the influences from 
>other running processes. First I tried grabbing the display 
>with gdk_x11_display_(un)grab. This didn't seem to improve the 
>results, but didn't make it worse either. I just decided to let it in.
>
>Then I decided to g_usleep (0) after a benchmark has finished. 
>I once learned that sleep (0) makes the kernel schedule other 
>tasks immediately, a kind of cooperative multitasking. ;) It 
>seems to have worked somehow since adding it reduced the time 
>difference from ~10% to ~7%.

Can we not just take the fastest run? As all the other influences
only *increase* the time, the fastest time would be the closest
to the real time it costs?

Of course, there is value in analyzing the variations (esp.
from the user perspective), but to get the pure numbers, taking
the fastest one should be ok.

Best wishes,
Dirk.