Michael, At first glance, your code is essentially establishling a baseline for the optimal timing the js user agent because each test is sequentially synchronized.
There is a clear difference with IE and FF. This is good and allow us to being proposing, if further required, a consistent solution for jQuery. What I am going to do, and you might to try this yourself if interested (since your JS coding is far superior to mine (for the mean time <g>) is: 1 - Perform multi-tasking timing test. This will give more "real life" applicability. This is basically firing 1, 2, 4, 8, 16 timeout dispatches to see how it degrades the system. Two set of test: 1.1 - A common dispatch should be all the same and have VERY little overhead. Mostly nothing. 1.2 - A common dispatch does some work. Ideally, the works should be two kinds, one that is small enough so that the pre-emptive context switching is minimize, and the second would be a more extensive work where the context switching is higher. In short, this will give us an overall "Coding Recommendation" that applets should minimize dispatch work (this is par for the course). But we can also gain insight on what jQuery work might be "too much" in dispatches. I realize this might be all for nothing, but atleast we will have a better grip on the timer issues and thus a better jQuery timer design, if possible, without the swags that inevitably creates QA problems. -- HLS On Aug 26, 3:54 pm, Pops <[EMAIL PROTECTED]> wrote: > Michael, > > Excellent piece of javascript code you have there to begin a real > benchment and summary report of all the browsers, machines, OSes > timing related issues. > > I didn't study it yet, but just running it on my XP box with IE and > FF, there are different results. I have to see what that means. > > Thanks for this. I'll have some more info soon. I would love to hear > from others who have working web sites or code with grooving jQuery > animation that can do a quick test with FastSleep.exe on their windows > station. > > PS: My gmail account was suppose to be my external testing, anonymous, > "sign up to whatever" junk account, but it has taken on a new life. > Hector is fine. :-) > > -- > HLS > > On Aug 26, 1:59 pm, "Michael Geary" <[EMAIL PROTECTED]> wrote: > > > Very interesting! I never thought about the effect that other applications > > might have on JavaScript timers. Thanks for posting that. (BTW, do you > > prefer to go by Pops or Hector?) > > > Here is something that may be useful in conjunction with your program. A > > couple of weeks ago when Yehuda was working on iPhone scrolling, I wrote a > > little test page that logs the timing for several repeats of setInterval() > > and setTimeout(), using intervals of 0, 1, and 100 milliseconds. > > >http://mg.to/test/interval/ > > > On IE, setInterval(0) does not work, so the page skips that test. > > > All the Windows browsers show the minimum 15ms time just like you said. On > > the Mac, Firefox shows a minimum setTimeout in the 3-4ms range, and a > > minimum setInterval around 11ms. Safari shows some 0ms timings for both > > setInterval(0) and setTimeout(0). iPhone has a minimum 10ms on setInterval. > > > Anyway, I hope that's helpful in any timer investigations. > > > -Mike > > > > From: Pops > > > > I am interested to hear any test reports for jQuery applications that > > > are using AJAX, any animation for PCs that might have altered the > > > system timer resolution. > > > > I posted an entry at my blog with discussing this, with a C/C++ > > > utility you can use to test to see how your applications behave in > > > normal sleep mode vs "fast Sleep" mode. > > > >http://santronics.blogspot.com/ > > > > Here is the fastsleep.cpp comments: > > > > // Utility to toggle the PC with Windows OS multi-media > > > // resolution that speeds up the Sleep() quantum. > > > // > > > // All PC has a quantum of 10-15ms regardless of the > > > // sleep value. Assuming the PC is 15ms, if you use > > > // Sleep(1), the time slice is 15ms. Sleep(18) is 30ms, > > > // and so on. > > > // > > > // This utility allows you to toggle the resolution > > > // to 1 ms. The actual delay is shown by this utility. > > > // > > > // Why? > > > // > > > // This can change the behavior of your applications > > > // which depends on timers, like many of the Web 2.0 > > > // Javascript applications. In Windows, the multi media > > > // function timeBeginPeriod() changes the resolution > > > // for the entire system. So if some other application > > > // is running with timeBeginPeriod(1) enabled, this > > > // will have a drastic effect on your Web 2.0 application. > > > // It may behave better, it may behave unexpectedly worst. > > > // It might explain someone reported to you, "hey this > > > // is not running right." But others don't see this, > > > // and you can't repeat it, so you just blew the report > > > // away. This utility can be use to design your > > > // application properly under all conditions. > > > > -- > > > HLS
