
Code: Select all
Changelog for 2.5.0.1
Added: All IPC is handled directly by the plugin allowing for the removal of the ES 1.4 SDK entirely
- Cuts package size in half
- Reduces average folder query/response time from ~5ms to under 3ms
Added: Timeouts as failsafes against possible ES/SizeES IPC thread hanging
Added: Expanded range of Status.ES message types and priorities
Added: Lower memory footprint by removing unnecessary long-path buffer allocation block
Previous releases have all had the ES SDK monolithically compiled into it, but after going through all his original code to see how it works there were a few things I decided to do a little differently (not least a proper HWND_MESSAGE proc which the plugin hosts), so I just tore it all down, rewrote it from scratch and did it the hard way (as usual).
(And why-oh-why was stpcpy never included in the standard C library? It's so much more useful than ordinary copy, though it needed a widechar version. My work is never done.)
The end result? Well, it's probably as robust, fast, and light as it can possibly be - the lean-and-mean version, if you will. As the changelog mentions, around 2-and-a-bit milliseconds have been shaved off the query/response time, which essentially makes it twice as fast as the old version.
v2.0.0.2 Test 1: 4901ms / 1000 folders = 4.90ms
v2.5.0.1 Test 2: 2752ms / 1000 folders = 2.75ms
Consider this: you can easily browse through 10,000 folders a day, and if you've saved 20,000 milliseconds for that day, and you have a life-expectancy of 73 years, I have single-handedly saved you 532,900 seconds or 6.168 days of time.

While I admit there may well be more than a few doubtful and glaring logical flaws in that scenario, as usual I'm easily amused, so hey...
By the way, those 8-bytes I fuss over? For those wondering, it's the size of the integer which holds the number of bytes in the foldersize. Yeah. Very exciting. An important and yet oddly useless piece of knowledge to start your day with. Long live the uint64_t.

Enjoy.