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
