File Explorer File Enumeration Slowdown in Windows 8.1 - Why?

Question

File enumeration in Windows 8.1 appears to be slowing down.
Here's what I mean:
On a freshly rebooted system (i.e., with few files in the cache), open a File Explorer window on the root folder of drive C:.
Select all the files, then right-click and choose Properties.
TIME how long it takes to finish, and divide the number of files enumerated by the seconds it took to do the enumeration.
Do it again now that the data is all cached.
I've always thought this was a decent way to gauge real world file system responsiveness, and in fact it really was a pretty good benchmark up until Windows 8.1 came along.  With Windows 8(.0) and earlier, if you saw more than 30,000 files per
second counted up, you had a very good SSD setup.
On the workstation on which I'm typing this, my Windows 7 x64 installation would enumerate about 30,000 files per second the first time, and about 50,000 files per second the second time, from the RAM cache.  I have a very responsive I/O subsystem.
When Windows 8 came out the numbers were about the same, if not a little better.
When Win 8.1 was released they dropped BIG TIME.  File enumeration was something like 3 to 1 slower.
Now, with the updates in past months, they appear to have dropped even further!
Right now, with a fresh bootup I am seeing just under 6,000 files per second enumerated the first time, and a bit over 8,000 from the cached data.  This is DISMAL by comparison to earlier versions.
Thankfully, typical file system performance - as measured by how long it takes to do real work on a few files in real applications - doesn't seem to have been affected as much, but then most applications don't enumerate lots of files. 
It seems likely that this enumeration slowdown affects real operations in Explorer beyond just this file count.
Keep in mind I can run a Windows 7 VM or Windows 8.0 VM on this same hardware and still see 30,000 files/second enumerated inside the VM.  My hardware hasn't degraded.  The older Windows systems are still just as fast.  If
I run a Win 8.1 VM the 6 to 1 slowdown is obvious.
That even the RAM-cached directory data can't be run through nearly as quickly in Win 8.1 says that the slowdown is in the file system implementation.
This isn't a question about why MY workstation is slowing down - it's not.  It's about why WINDOWS is becoming less and less efficient out of the box.  I have measured and compared progressive slowdowns in virtual machine snapshots
ranging from a fresh, out-of-box installation of Win 8 or 8.1, to one that's been run for years.  Something's becoming less efficient IN THE DESIGN.
So...
Why is File Explorer taking longer and longer to simply count up files in folders?
A corollary question is:  What else is this slowdown affecting?  Explorer doesn't seem as responsive to me as it once did.
I'd hate to think Microsoft is slipping stuff into Windows to cause it to be slower and slower since its release date, just so they can make it look like the next version is faster.
-Noel
Detailed how-to in my eBooks:  
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" Options

Answer 1

 the slowdown is in File Explorer, rather than the file system itself.
Want some more proof?  And proof that your system is caching the data that is needed.  And proof that stuff may be being ignored by WE which should be counted...
In an elevated cmd window at the desired drive root enter:
D:\>dir/a/s | findstr "File(s) Dir(s)"
The surprise for me is the way the pipe seems to work?   Is it really a separate process that doesn't have to wait for the completion of the first stage's output?
Anyway, I might be willing to time that--in fact, it may be possible to automate its timing--but I am definitely not interested in hanging around waiting for the number of
minutes that WE takes to be sure I get an accurate measurement--if you know what I mean.   <eg>
And apparently that would not be a fair comparison anyway.  WE only finds 2/3 in Size of what the dir finds.  I probably need to tweak WE's Options.  Finding only 2/3 of what another procedure is finding seems suspect even if it does
take an absurd amount of time longer.  The funny thing is that the number of files is almost the same.  So, what does that imply: that 1/3 of the Size was contained by some very few which could not be counted?
I should probably also try to convert that pipeline to Powershell and see how it does.  That could at least check the dir measurements in one way or another.  TBD.
BTW I think I am now on a faster processor than I had with my tx2 but this Surface 2 Pro even with 8 GB RAM still doesn't "scream" for me.  I have noticed that its firmware shuts down cores occasionally. 
My guess is that could be due to its lack of cooling.  My tx2 always had its fans running full.  Maybe I will get a different result if I do this test in the winter than now in the middle of summer?   <eg>
Robert Aldwinckle