A while back, I remember tuning the default priority in HandBrake's preferences, back when I made the leap over to HEVC. Mainly because the encode times are so long on my old Core i5-3570K, and because I tend to leave such jobs running overnight.

Well, for curiosity sake I've decided to see how monkeying with this changes things a bit.

In my experience, nicing processes on my unix systems is rarely worth the bother. That is to say, a nice system like Linux this side of multi-core processors tends to remain pretty responsive, and most people I encounter screwing with niceness tend to be pissing down the wrong problems to start with. But NT is not unix, nor Linux, so who knows.

Looks like the default priority I had configured was "High". Task Manager also shows a "Real Time" but that isn't in the GUI.

Net result is Handbrake proceeds at a pace of roughly 8.9 ~ 9.5 frames per second. Which works out to being closer to 9 than 10. Set to high priority also means that while the encode is running my desktop session is virtually useless, as things like updating UI state takes a back seat to next Tuesday.

After the first item in my queue finished, and the next began: I lowered the priority to "Above Normal". Impact on encode is roughly 8.9 ~ 8.3 frames per second on the average county thingy. So that's a performance loss of about 3 ~ 6 percent, but my desktop session is actually usable. UI updates like the process table in task manager now update in something closer to real time than melting an Titanic sized iceberg with a zippo lighter, and general productivity is passable. Typing this post is about on par with running a web browser on an older computer. Small price to pay.

That roughly equates to the encode takes less than five minutes less, if I render my desktop useless until the task finishes. Provided current pace keeps. When the entire encode takes a bit more than an hour per episode, it's kinda a meh perspective. Also a little nicer seeing my processor bouncing between ~70% and 99% in task manager instead of 97 ~ 99 %, lol.

I'm kind of reminded of XP, and my opinion that it could be very stable if you didn't do nasty things (or need shit drivers) to it, but being user responsive when under heavy loads it was not. As beautifully as the NT desktop has evolved since then, I still don't think melting a Windows box is as smart an idea as melting a Linux box, if you've really got to melt your system's load.

When the third file starts encoding, I'll probably try dropping the priority to normal and see what happens.