3 ms·
regarding the timestamp performance optimization, seems like the more robust solution is using setTimeout to avoid blocking the main thread with timestamp updat
by kwamenum86 16y ago
regarding the timestamp performance optimization, seems like the more robust solution is using setTimeout to avoid blocking the main thread with timestamp updating. basically you perform updates on a set amount of nodes and then defer the updates for the rest using setTimeout. This scales to any number of DOM nodes but the solution outlined in this post works for the vast majority of use cases.
- altano 16y agosetTimeout does not run in a background thread that can be parallelized. There is no "main thread" vs. "background threads." If you write an endless loop in a setTimeout callback, none of your other JS will ever run. You can easily test this: setInterval(function(){ console.log("hi"); }, 500); setTimeout(function(){ while(true) { console.log("no more hi"); } }, 100);
- spullara 16y agoWhy wouldn't you use a setTimeout per timestamp set to go off a bit after the next time it should be updated? Seems like that would have a spread distribution and would also minimize the amount of work done.
- kwamenum86 16y agoNot per timestamp. Per x timestamps. For example, update 80 timestamps in 4 batches of 20. This should perform well in all cases because we are doing a predictable amount of work.
- kwamenum86 16y agoYeah "main thread" was a misnomer/mistake. I should have just said thread. But that is exactly my point- running a long loop will block js execution but their solution only avoids the problem in most cases. I think the better optimization is to go through a subset of the timestamp iterations and keep using setTimeout's to do the remainder of the work until all of the timestamps are updated e.g. update 80 timestamps in 4 batches of 20. This is not an original idea- it's considered a best practice in client side programming.