This design is due to the fact that there's massive memory leaks using onreadystatechange. There's simply no way to use it without it leaking massive amounts of memory all over the place. You'll find that any reasonable, modern, implementation of Ajax functionality uses this technique as well. And if it doesn't - run for the hills.
As far as the interval goes, browsers simply ignore small numbers to setTimeout and bump them up to their minimum value (whatever it is). There was an issue in Safari (if I remember correctly) where if you specified a number too low, it would execute it immediately, as opposed to asynchronously. If you're not seeing any progress indicator, then you're probably loading a document from the cache. One user added it to jQuery core, as it interested him, and it worked just fine, you can see the patch and ticket for it here: http://dev.jquery.com/ticket/1172 --John On 8/24/07, Pops <[EMAIL PROTECTED]> wrote: > > Oh John, I just noticed this line in .ajax() > > // don't attach the handler to the request, just poll it instead > var ival = setInterval(onreadystatechange, 13); > > Can you explain the design theory behind requiring your own timer and > poll? > > You guys must have you reasons on that, but here are my thoughts: > > This frequency you have there is basically the default quantum of > Intel based CPUs. It is far too low creating high context switching. > This should be increased as well as provide developers a way an option > to set it. But that is still a problem with that. > > I added this logic to my own ajax code to see the reasons. I find > this is skipping the natural states in the XMLHttpRequest() protocol. > For example, the 13 ms quantum you have is only showing states 1 > (load) and 4 (complete). > > Maybe you guys have believe the states are meaningless, but this > changes the design of the backend protocol. I wondering why? What if > a developer is interested in that information? What if it is altered > with a new "meaningful" state? > > In leiu of finding out why that logic is done this way, I still say > that frequency is way to low. You might as make it 1 ms! since that > will give you the full quantum for the machine CPU type. > > Typically this will not need more than maybe 50 to 100ms per state for > HTTP request. You improve the efficiency of the machine by having it > higher, without slowing down AJAX perfornance > > But to the illustrate the problem, if you change the value to > something higher, you can miss other states, like changing that to > 50ms and state one is missed. > > In threaded, sychronization design, it is typically best to let the > protocol itself drive you, not you drive it with "artificial, best > guess" timing which in inevitable, in some form or fashion, creates > timing headaches. > > Where you concern with redundant callbacks? > > --- > HLS > > > On Aug 24, 12:48 pm, "John Resig" <[EMAIL PROTECTED]> wrote: > > No, this is final - the blog post contains the full release > > notes:http://jquery.com/blog/2007/08/24/jquery-114-faster-more-tests-ready-... > > > > Do you have any specific Ajax improvements? > > > > --John > > > > On 8/24/07, Pops <[EMAIL PROTECTED]> wrote: > > > > > > > > > Great job John! > > > > > I think you hit it on the nose on what was the primary focus - > > > optimization! > > > > > Questions: > > > > > Is this consided a beta, gamma or production release? I ask because I > > > don't see it announce at jquery.com at the moment of this posting. > > > > > If there is still an window for improvements, I have a number of > > > suggestions for the ajax system. Best on my current knowledge of > > > jQuery, one suggestion ideally calls for a small unobstrusive change > > > to the extensive $.ajax function itself. I was currently working on > > > this when I was going to post a message about it, and I saw your > > > announcement. While an override plugin would do, the .ajax() method > > > is the bulk of that logic and it doesn't seem feasible to replace that > > > function for one small 1-2 line change. The other suggestions are > > > small enough to be plugins but it requires the change to the .ajax() > > > method. > > > > > Thanks! > > > > > -- > > > HLS > > > > > On Aug 24, 4:46 am, "John Resig" <[EMAIL PROTECTED]> wrote: > > > > Hi Everyone - > > > > > > jQuery 1.1.4 has just been released! The full details of this release > > > > can be found on the jQuery > > > > blog:http://jquery.com/blog/2007/08/24/jquery-114-faster-more-tests-ready-... > > > > > > Suffice it to say that some significant speed increases, test coverage > > > > increases, and API reductions have been made. Please let us know if > > > > you encounter any new problems from jQuery 1.1.3.1. > > > > > > --John > >
