Monitoring Performance

(a.k.a. How often shall we defer to the UI?)

In my effort to build a simple clipboard copy button, I found the need to in-line styles if they are to survive emailing, and that in-lining could, for very large elements be rather costly (in time), of which was born a need to let UI events happen while doing the job.

With all that under my belt, knowing how long it was likely to take would also be nice, a bit of UI feedback on progress of the style in-lining operation. Basically, a progress bar ...

Progress bars were once a problem in JavaScript, with lots of tips, tricks and 3rd party solutions. But no more, we now have the progress element and it's a breeze. We can just add:

<progress value="0"/>

to a button, or elsewhere, and style it as we wish, display it as needed and update it's max and value to suit. The default width, it seems, when we put I on my page was around the 150 pixels mark, but it can be styled as desired.

And that answers our "How often shall we defer to the UI?" question implicitly. While not a fault-free, universally-suitable answer, it's not a bad start to update no more often than it takes to advance that progress bar by one pixel (i.e to make a visible change to it).

For 100,000 elements say and a 150 pixel bar that's an ominous 666 elements per pixel.

If we drop the frequency of deferrals to the UI to once every 666 elements they are in-lined in 42 seconds (an auspicious figure). Much improved performance.

To recap:

• 30 seconds with a locked UI,
• 11 minutes if we defer to the UI after ever element (~100,000 times - i.e. 30 seconds of style processing an 10+minutes of promise management), and
• 42 seconds if we temper the UI deferrals to 150 times over the duration of in-lining (for a 150pixel progress bar).

Empirical tests confirm that, during those 42 seconds, the UI is admirably responsive, no noticeable lag and so we're content!

But still, in 42 seconds the element being copied might change! That is, because we are deferring to the UI and maintaining responsive UI while in-lining styles, user events processed can change the element that we're copying! So we need to both know something has changed and start again if it has, but that is another chapter of The Thing Is ...