Ok, there is always a reasons for something. I appreiciate you taking
the timeout to share it.
I think the problem with that patch is that there are redundant
XmlHttpRequest callbacks per state. The proper coding would wait
for the state to change.
var lastState = -1;
var onreadystatechange = function(isTimer) {
if (xml.readyState && (lastState != xml.readyState)) {
lastState = xml.readyState;
......
}
}
adding the suggestions with the optional timer would be wonderful <g>
var lastState = -1;
var onreadystatechange = function(isTimer) {
if (xml.readyState && (lastState != xml.readyState)) {
lastState = xml.readyState;
if (s.monitor) s.monitor(xml);
....
}
}
if (s.pollFrequency) {
var ival = setInterval(onreadystatechange, s.pollFrequency);
} else {
xml.onreadystatechange = onreadystatechange;
}
--
HLS
On Aug 24, 8:18 pm, "John Resig" <[EMAIL PROTECTED]> wrote:
> 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
