Avoid wasting a whole thread watching for a filesystem change 😬

[JasonElkin]

Prerequisites

• I have added steps to test this contribution in the description below

Description

I was profiling an Umbraco v15 solution last week and noticed that about 1% of the CPU time was spent... sleeping 😱

Turns out a whole thread was spending most of their time sleeping on the job! Woken up every 2 seconds to do a miniscule amount of work, then sent back to sleep.

That thread's clearly not pulling their weight - so I figured I'd send them to the pool to hang out with their friends and maybe do something else useful in the meantime. Serve some webpages, run a scheduled task or two, anything except sleeping!

Testing

Profile the site (I used DotTrace) before and after the change and notice how much CPU time is spent sleeping...

Before

Idling on my test site - 2.6% 😴

After

Absolutely none 😃

---

As an aside, the approach in this method isn't ideal. There are more efficient and robust ways to handle this than a while loop, e.g. System.Threading.Timer or a FileSystemWatcher but I didn't want to embark on a refactoring without some HQ guidance and Task.Delay at least solves the immediate performance problem.

[github-actions]

Hi there @JasonElkin, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[emmagarland]

Hi @JasonElkin

Good spot and description! One of your fellow Core Collabs will take a close up look soon.

Thanks,
Emma

[PhyxionNL]

I know this is merged already, but this should really pass in the CancellationToken.

[mikecp]

@PhyxionNL Thanks for the feedback 👍

Feel free to create your own PR and we'll gladly review it 😁

[JasonElkin]

Oh boy, we've chosen the red pill here...

Let me ask you: "What cancellation token"!?!?!

The one that comes from the private readonly CancellationTokenSource...?
The one that's not referenced from anything else... so is never actually cancelled!?!