This is making me think seriously about changing the timing parameters of Watir's wait method.
My proposal would be to wait until 1.6.5 was released and then follow that shortly with a 1.6.6 release that uses Tim's parameters. Thoughts? Bret On Wed, Oct 14, 2009 at 10:04 PM, Tim Koopmans <[email protected]> wrote: > Cool! > > When using 0.01 instead of 0.20 seconds for a_moment, the following > differences were noted: > > iexplore.exe > +0.27% overhead for the mean > +1.88% overhead for the median > > ruby.exe > -0.85% overhead for the mean > +0.30% overhead for the median > > Metric sampled was \Process(ruby | iexplore)\%Processor Time every 5 > seconds for approximately 10 minutes using the same test case for each > run. > > When comparing @down_load_time to session times (observed in fiddler = > network + server time) I am getting an average of 0.7 secs, which is > assumed to be client render time with sleep a_moment = 0.01. > > The same test was showing client render time with an average of 1.4 > secs with sleep a_moment = 0.20 > > I'm much happier with a_moment set to 0.01 for now. > > > > Thanks, > Tim Koopmans > > > > On Thu, Oct 15, 2009 at 12:27 PM, Bret Pettichord <[email protected]> > wrote: > > Good question. Probably some of both, but only one way to find out! Put > it > > to the test. > > > > Bret > > > > On Wed, Oct 14, 2009 at 8:23 PM, Tim Koopmans <[email protected]> > wrote: > >> > >> Also which process would be most affected by this change? > >> ruby.exe or iexplore.exe? > >> > >> Regards, > >> Tim Koopmans > >> > >> > >> > >> On Thu, Oct 15, 2009 at 12:15 PM, Tim Koopmans <[email protected]> > >> wrote: > >> > That's fine Bret, totally understand, and thanks for introducing me to > >> > the heisenberg principle! > >> > > >> > I'm happy to mix in my own module for this case, as accuracy is what > >> > I'm after. I'm also correlating results with fiddler traces at the > >> > same time for single test cases with about 30 steps. I'll keep an eye > >> > on CPU/mem but I'm on a fairly decent spec'd box (for loadrunner) so > >> > no problems observed yet with Intel core 2 duo (2.39GHz) and 2GB RAM. > >> > > >> > > >> > > >> > Regards, > >> > Tim Koopmans > >> > > >> > > >> > > >> > On Thu, Oct 15, 2009 at 12:01 PM, Bret Pettichord < > [email protected]> > >> > wrote: > >> >> On Wed, Oct 14, 2009 at 7:29 PM, Ethan <[email protected]> wrote: > >> >>> > >> >>> You could get more precise results by dropping a_moment from 0.2 to > to > >> >>> something much lower, 0.01 or something. I don't think it would make > a > >> >>> difference to anything else; a hundredth of a second is still a > >> >>> relatively > >> >>> long time compared to how long the ruby code around this should take > >> >>> to > >> >>> run. > >> >> > >> >> You need to be careful about dropping the polling interval too low. I > >> >> tried > >> >> several values, and this is what seemed to me to be the one that gave > >> >> Watir > >> >> the best performance. If the polling interval is too long, then you > >> >> risk > >> >> "wasting" time -- on average you will waste half of the polling > >> >> interval on > >> >> each wait. > >> >> > >> >> On the other hand if the polling interval is too short, then the act > of > >> >> polling itself consumes more CPU, thus slowing down other processes > >> >> (including the browser rendering). > >> >> > >> >> This is really a heisenberg principle. The smaller the polling > >> >> interval, the > >> >> more accurate the result, but the more the act of measurement has > >> >> changed > >> >> the thing being measured. > >> >> > >> >> On the other hand, it has been a long time since I chose the 0.2 > >> >> polling > >> >> interval. We have newer versions of IE and now typically have more > >> >> powerful > >> >> machines. I'm open to changing this interval if some one does some > >> >> experiments and has a better suggestion. But also note, that my goal > >> >> has > >> >> been to make Watir as fast as possible, even if that means that the > >> >> timings > >> >> aren't as accurate as possible. > >> >> > >> >> Bret > >> >> > >> >> _______________________________________________ > >> >> Wtr-development mailing list > >> >> [email protected] > >> >> http://rubyforge.org/mailman/listinfo/wtr-development > >> >> > >> > > >> _______________________________________________ > >> Wtr-development mailing list > >> [email protected] > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > > > -- > > Bret Pettichord > > Lead Developer, Watir, www.watir.com > > > > Blog, www.io.com/~wazmo/blog <http://www.io.com/%7Ewazmo/blog> > > Twitter, www.twitter.com/bpettichord > > > > > > _______________________________________________ > > Wtr-development mailing list > > [email protected] > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Lead Developer, Watir, www.watir.com Blog, www.io.com/~wazmo/blog Twitter, www.twitter.com/bpettichord
_______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
