Re: [Efficient Script Yielding] - Clamping

Read the spec. setTimeout() is only clamped when nested, that is the clamp
only applies when setTimeout() is invoked within the context of another
timer firing.

- James
On Jul 2, 2011 10:35 AM, "Kyle Simpson" <getify@gmail.com> wrote:
>>> Would it be possible to resolve these issues by specifying that if
>>> setImmediate() is called raw (that is, not from inside a timer handler),
>>> then it basically has no clamping and is ASAP, but if it's called from
>>> inside a timer handler (setTimeout, setInterval, setImmediate, etc),
>>> then it's ok to clamp it?
>>
>> How would this differ from setTimeout(..., 0) ?
>
> I was under the impression from previous threads that even the raw (not
> nested) call to setTimeout(..,0) was clamped to happen no sooner than 4ms.

> If that's an accurate statement, then the difference would be that the
> first-level setImmediate() would be able to run un-clamped (subject to the

> UA being able to service the call as soon as possible).
>
> If setTimeout() already runs un-clamped on its first-level call, then I'm
> not sure what all the discussion has been about here, because as I said,
it
> seems to me like the 99% use-case for setImmediate() is for first-level
> yields, not for nested/recursive calls for animations.
>
> Another thought (quite possibly off base)... is the clamping done because
of
> the inefficiency of a rapidly repeating script making changes to the DOM
(or
> styles) and requiring repaints/reflows? If a tightly running loop doesn't
do
> anything but change values in JS variables (doesn't affect the DOM/CSS),
is
> clamping as necessary? If it's less necessary, perhaps browsers could
allow
> the bubble-sort use-case (the yield step in an algorithm) to run
un-clamped,
> but if a piece of code affects the DOM/CSS in any way, then clamping kicks

> in?
>
> I dunno, just some thoughts.
>
> --Kyle
>
>
>
>
>