nonesuch at longcount.org
Thu Jan 27 22:53:50 UTC 2011
On Thu, Jan 27, 2011 at 4:58 PM, Devin Teske <dteske at vicor.com> wrote:
> On Thu, 2011-01-27 at 23:35 +0200, Kostik Belousov wrote:
> On Thu, Jan 27, 2011 at 09:12:34PM +0000, Devin Teske wrote:
>> On Thu, 2011-01-27 at 22:59 +0200, Kostik Belousov wrote:
>> > On Thu, Jan 27, 2011 at 08:50:48PM +0000, Devin Teske wrote:
>> > > Probably did something like this:
>> > >
>> > > time sh -c '( firefox & ); sleep 10000000'
>> > >
>> > > and then pressed Ctrl-C when he felt that firefox was finished
>> > > loading.
>> > > The moment Ctrl-C is pressed, time(1) shows how long it ran up until
>> > > you
>> > > pressed Ctrl-C.
>> > > NOTE: Pressing Ctrl-C will not terminate the firefox instance.
>> > You cannot have 1/100 of seconds precision with this method.
>> > This is why I am asking, seeing < 0.1 seconds difference.
>> > Not to mention some methodical questions, like whether the caches were
>> > warmed before the measurement by several runs before the actual
>> > test.
>> $ time sh -c '( firefox & ); sleep 10000000'
>> real 0m5.270s
>> user 0m0.000s
>> sys 0m0.005s
>> I'd call that 1/100th of a second precision, wouldn't you?
>> HINT: Try using bash instead of csh.
> (I supposed that) obvious point of my mail is that you cannot reliably
> measure 1/100 second intervals when human interaction is involved.
> To make it completely obvious: human has to press CTRL-C, I did not
> mean reading the numbers from display.
> I hypothesized that the results would always be subjected because we
> couldn't tell whether one person would consider "complete" to be "web page
> loaded" versus another person might consider "complete" to be when the
> window frame/decorations are drawn by the window manager.
> However, if Firefox provides a way of timing it in an objective manner...
> that would surely be superior to the method I've suggested which can lag by
> a few hundreds of even a few tenths of a second (depends on the subject's
> ability to quickly invoke focus-follows-mouse and press Ctrl-C).
> So yeah... my suggestion isn't perfect... but is generally "good enough" if
> the application you're testing doesn't provide a hook for determining when
> it is officially done loading.
> Now... here's an idea that might work (since we're talking about a web
> browser -- this obviously won't work for OpenOffice, though variations on
> the idea can be had):
> 1. Launch Firefox from the command-line with arguments to point it at a web
> 2. Execute: ps axo pid,state,command,lstart | grep firefox
> 3. Calculate the time difference between the "lstart" and the time printed
> in the browser.
> I do believe that should be sufficient to get accurate/objective results.
> NOTE: For OpenOffice, you could perhaps have the spreadsheet program open a
> spreadsheet with a macro to display the current date/time then use the
> lstart data from ps(1) to calculate the results. Similarly, you could have
> OpenOffice.org Writer open a document with a header-macro to display the
> current date/time.
So for both I took the simplest approach . I spent to much time on
looking for more exotic solutions.
This seamed to be the easiest to run and somewhat os / platform agnostic.
1. time application " time firefox"
2. kill it when its fully loaded. *
3. record time
4. rerun test 10 times make an average to normalize my response time
in closing the application.
* I have the window manager open the window in the same place so I
could be ready to hit the close widget.
* For firefox I had it set to load a local page on startup
* For openoffice I waited till it was at the "what do you want to do" window
I know there is a lot of room here to debate how fast I can close and
application, what's cached , how busy is the disk etc. I tried using
mplayer but I did not get good results. My logic in using mplayer was
that its linked to almost every audio / video lib you can name. Making
it do some task, dump every frame into a jpg or remove the audio track
from some video etc, should be simple to test without using a gui or
requiring human input to stop it.
I am stumped, at first I just was curious at first if there was any
truth in the post, and wanted to know if anyone looked into it. Now I
want to know how you test this correctly.
mark saad | nonesuch at longcount.org
More information about the freebsd-hackers