Macro micro12/11/2023 ![]() And its overall execution time isn’t much longer. So the earlier we schedule it – the faster it runs.įinally, we’ve split a CPU-hungry task into parts – now it doesn’t block the user interface. Even if we set 0, it’s 4ms (or a bit more). That’s simple: as you remember, there’s the in-browser minimal delay of 4ms for many nested setTimeout calls. If you run it, it’s easy to notice that it takes significantly less time. ![]() Now when we start to count() and see that we’ll need to count() more, we schedule that immediately, before doing the job. SetTimeout(count) // schedule the new call We’ll move the scheduling to the beginning of the count(): To make them closer, let’s make an improvement. There’s not much difference in the overall counting time. The notable thing is that both variants – with and without splitting the job by setTimeout – are comparable in speed. Periodic returns to the event loop between count executions provide just enough “air” for the JavaScript engine to do something else, to react to other user actions. ![]() onclick event) appears while the engine is busy executing part 1, it gets queued and then executes when part 1 finished, before the next part. Now the browser interface is fully functional during the “counting” process.Ī single run of count does a part of the job (*), and then re-schedules itself (**) if needed: SetTimeout(count) // schedule the new call (**) For server-side JS that’s clearly noticeable, and if you are running it in-browser, then try to click other buttons on the page – you’ll see that no other events get handled until the counting finishes.Īlert("Done in " + (Date.now() - start) + 'ms') If you run the code below, the engine will “hang” for some time. To demonstrate this approach, for the sake of simplicity, instead of text-highlighting, let’s take a function that counts from 1 to 1000000000. Highlight first 100 lines, then schedule setTimeout (with zero-delay) for the next 100 lines, and so on. We can avoid problems by splitting the big task into pieces. It may even cause the browser to “hiccup” or even “hang” for a bit, which is unacceptable. While the engine is busy with syntax highlighting, it can’t do other DOM-related stuff, process user events, etc. To highlight the code, it performs the analysis, creates many colored elements, adds them to the document – for a large amount of text that takes a lot of time. Use-case 1: splitting CPU-hungry tasksįor example, syntax-highlighting (used to colorize code examples on this page) is quite CPU-heavy. Now let’s see how we can apply that knowledge. That happens when there are a lot of complex calculations or a programming error leading to an infinite loop. So after a time, it raises an alert like “Page Unresponsive”, suggesting killing the task with the whole page. If a task takes too long, the browser can’t do other tasks, such as processing user events.Changes to the DOM are painted only after the task is complete. It doesn’t matter if the task takes a long time. Rendering never happens while the engine executes a task.When the engine browser is done with the script, it handles mousemove event, then setTimeout handler, and so on. Tasks from the queue are processed on “first come – first served” basis. The tasks form a queue, so-called “macrotask queue” (v8 term):įor instance, while the engine is busy executing a script, a user may move their mouse causing mousemove, and setTimeout may be due and so on, these tasks form a queue, as illustrated on the picture above. It may happen that a task comes while the engine is busy, then it’s enqueued. Tasks are set – the engine handles them – then waits for more tasks (while sleeping and consuming close to zero CPU). When the time is due for a scheduled setTimeout, the task is to run its callback.When a user moves their mouse, the task is to dispatch mousemove event and execute handlers. ![]() When an external script loads, the task is to execute it.The JavaScript engine does nothing most of the time, it only runs if a script/handler/event activates. That’s a formalization for what we see when browsing a page. Sleep until a task appears, then go to 1.execute them, starting with the oldest task.There’s an endless loop, where the JavaScript engine waits for tasks, executes them and then sleeps, waiting for more tasks. In this chapter we first cover theoretical details about how things work, and then see practical applications of that knowledge. Understanding how event loop works is important for optimizations, and sometimes for the right architecture. Browser JavaScript execution flow, as well as in Node.js, is based on an event loop.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |