On Aug 25, 9:30 pm, "John Resig" <[EMAIL PROTECTED]> wrote:
> > I just took a look at prototype.js and mootools.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.
Ok, I believe you, but I hope you don't mind if I tried to confirm
this. Just curious. :-)
I'll check out YUI and DoJo.
> 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.
/**
* Interval delay in milliseconds, defaults to fastest possible.
* @property delay
* @type Int
*
*/
this.delay = 1;
Where do I begin?. I don't want to say this the wrong way. I am
beginning to feel I am losing my welcome here.
First, to get out of the way, YUIi makes it optional. jQuery does
not. So please consider this at a minimum for jQuery.
Second, Yahoo has been known to change the multi-media timing
resolution in their applications to make their applications "appear"
to run faster.
http://www.codeproject.com/tips/YahooSpeeds.asp
I was able to confirm this back then.
So who knows what the developer of this code was thinking when he/she
set this value to 1. Maybe you do need it for animation. Maybe he had
yahoo finance running at the time and it mistakely thought that 1ms is
the "Fastest Possible" when it fact it is not. Zero ms is the
fastest. The problem is that 0ms is so fast, it will create a massive
CPU hogging. So you don't want 0ms. 0ms tells the schedule
"Ok, queue me for the next quantum, but if no one is busy,
start me again"
So there are is tremendous amount of interrupts and context
switching. These applets are not friendly.
But if the 1ms resolution is set on the machine using the multi-media
functions, that 1ms frequency will also hog the CPU just was well. So
its not very system wide optimal setting. Great for YAHOO, things are
FAST - the rest of the applications are slowed down.
> 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.
Yes, I undersand JS is not multi-threaded, but the XHR interface to
the OS native user agent is multi-threaded. No? So you have two
threads: the JS and XHR. The JS thread keeps runnning as the
background thread is running. The jQuery timer() method will miss
some states. That have been confirmed for sure.
> - 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).
I didn't presume they did. The single -threaded js is working with the
XHR thread. Is it not? Are you saying XHR is using synchronous
sockets?
No that can't be, you are missing states. That implies two threads!
If it was 100% all 1 thread that means its using a mult-tasking
approach, and that would mean that no states will be missed. That is
not what I am seeing.
> - 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 the browser might see a 0ms passed, and say "Nah! Sorry, thats too
expensive. I'm going to use X?"
> So, yes, we might as well pick 1ms, Yahoo UI seems to think it's ok,
You will not see any difference, until someone changes the multi-media
timer which will definitely be speeding up jQuery move pre-emptive
context switching - slowing down the rest of the system.
Also, what about the draft XmlHttpRequest() work? They are planning
to add new events hooks? Is jQuery going to ignore these too because
it may have already cover these ideas?
> 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.
I say:
1) Make the timer optional. I rather be an conformant with the
standard.
2) If you must keep the time, atleast make the freq variables
adjustable.
> The issues at play here are phenomenally more complicated, and
> nuanced, then they're made out to be.
I am sorry if that you got the wrong idea but I made two unobstrusive
suggestions:
- optional timer,
- optional frequency
But I personally feel this is the wrong approach. My opinion. I tried
to give practical reasons and I can see that it won't be compatiable
with the next version of XHR standards with new considerations..
I am having a hard time grasping why an API is mandating how XHR
should be used with less flexibility in two critical areas than it has
for the rest of the jQuery framework.
Thanks for your time.
--
HLS
