At the moment, incremental scheduler runs a repeating task in a while loop
that checks if its duration has exceeded 16ms and then returns control to
the browser.
If you assume that an incrementally scheduled task will tend to run in
about the same time as it did before then you can get about a
I think we do not want to make any assumptions about runtime of any tasks
since this would not work well with task that have variable runtime.
If you need to do heavy calculations since browser APIs have evolved a lot
you should be using web workers anyway.
On Wed, Jan 14, 2015 at 11:57 AM, Richa
You can't use webworkers to process the dom / xml, or do layout which is
pretty much all my long running tasks do.
Agree this is too dangerous to just add to the existing api but if you
added a new method scheduleConstantTime() that ran the optimization it
might be useful.
On Wed, Jan 14, 2015 a
Actually in defense of adding the optimization to the current api.
It can be made safe by only ever setting lastLoopCounter to
min(lastLoopCounter + 1, loopCounter).
That should cause similar improved performance for multiple second tasks
without ever having a lower frame rate than the current sc
Just an update, there's a bug in my original implementation which causes
the loopCounter to tend to increase until the task ends.
After removing the bug, the performance increase is only about 8% for the
fibonacci sequence.
Also the safer version where the loopCounter increments by at most 1
elim
Also, your approach is assuming that all tasks in the queue are "the same
task" that needs repeating. But what if I schedule 2 incremental tasks?
On Wednesday, January 14, 2015 at 3:07:47 PM UTC+1, Richard Wallis wrote:
>
> Just an update, there's a bug in my original implementation which causes
Still very much a draft but I've settled on two approaches:
Calculating the fibonacci sequence either approach performs about 5x better
than the curent scheduler.
Fibonacci sequence is thousands of very short operations so it does very
well the more the duration check is skipped. Real world task
>
> Also, your approach is assuming that all tasks in the queue are "the same
> task" that needs repeating. But what if I schedule 2 incremental tasks?
Loop count code takes this into account and only runs if the length of the
task queue == 1.
The second approach where you divide the TIME_SLICE
Ah second implementation has a bug again that makes it much faster than it
should be I'll post the fix and the actual speed up, if any, shortly.
On Wed, Jan 14, 2015 at 5:34 PM, Richard Wallis wrote:
> On a side note the Scheduler implentation needs to be rewritten to make it
> easier to provide
On a side note the Scheduler implentation needs to be rewritten to make it
easier to provide alternative schedulers while letting those alternative
schedulers use as much of the core code as possible.
It would be easier to make these patches if runRepeatingTasks was protected
and there was a Sched
Fixing the bug didn't change the performance noticably:
Bug fix is:
quickRunCount = (int) (((TIME_SLICE - 1) * runCount) / elapsedMillis);
becomes:
quickRunCount = (int) (((TIME_SLICE - 1) * runCount) / elapsedMillis) -
runCount;
On Wed, Jan 14, 2015 at 5:37 PM, Richard Wallis wrote:
> Ah se
>
> It's dangerous in the current implementation because the faster job can
> die before a slower job messing up the estimate.
The above is wrong, any task finishing will make the estimate too low
(which is safe) rather than too high.
On Wed, Jan 14, 2015 at 5:25 PM, Richard Wallis wrote:
> Al
12 matches
Mail list logo
