John, I've been doing some digging to find that leak and I believe it had been resolved since the 5th ticket in our Trac. http://dev.mootools.net/ticket/5
I also don't encounter any leaks in my own tests. -Olmo M. On Aug 25, 8:30 pm, "John Resig" <[EMAIL PROTECTED]> wrote: > > I just took a look at prototype.js andmootools.js, neither are > > depended on a "Lets hope if this best guess 13ms always works" timer > > concept. > > Right, so they leak every single time you use them, both libraries are > quite naive about the issue of memory leaks. > > If you're looking for some form of justification for what we're doing > look at Yahoo > UI:http://sourceforge.net/project/downloading.php?group_id=165715&filena... > > In build/connection/connection.js look for handleReadyState which does > all the polling. > > Also, Dojo is using this particular method for querying XHR > state:http://alex.dojotoolkit.org/?p=528 > > Yahoo UI is also using a polling interval of 50ms for XHR, which they > seemed to just pick arbitrarily. Just to emphasize that point, look in > Yahoo UI's build/animation/animation.js where they set their delay on > their animation timers to 1ms. > > I think you're missing a couple points here: > - JavaScript engines are not multi-threaded. There's no such thing as > a locking or synchronization issue within JavaScript. The XHR request > won't return or finish until the current JS is finished executing. > - setTimeout and setInterval do not create threads. The push functions > onto the JavaScript stack to be executed at a later time (so if a > script never stops running a timeout will never be called). > - The units passed to setTimeout are arbitrary, it's still at the > browsers discretion as to when they're actually executed. They're not > sent straight to the processor for handling - all operations are > delegated by the browser. > > So, yes, we might as well pick 1ms, Yahoo UI seems to think it's ok, > there's no particular reason for not doing so - nor has it made any > particular effect upon the system for not having done so. In the case > of Ajax, the query rate could probably be slowed down to something > like 50ms, and for animations, increased to something like 1ms. > > The issues at play here are phenomenally more complicated, and > nuanced, then they're made out to be. > > --John
