Maybe you have lazy updates 
I don’t know what the lazy caching does and I suspect it to be only relevant when entering new folders, but simply try it. There is also an option in pref > file browser “showing embedded jpeg as thumbnail…” you could try. You might need to delete/rebuild the cache for this option to take effect. A little further down on the same page. I don’t have this delay, all my options are pretty much default.
A funny thing: Be sure there is no compatibility mode set for ART.exe in Windows… I once had that for DT and wondered why its browser was so laggy until I accidentally found out. 
No idea why it was activated. Maybe there was a crash and Windows did some “problem solving”. 
Actually I do… 
I don’t know for sure what it does but ISTR in other apps similar features allowed folder contents to populate “unthumbnailed” (with a generic icon, etc.) for a moment or two while the thumbnail population caught up rather than wait on each individual image and cause delays. But there’s already a setting for that, so I dunno… Maybe @agriggio can help clarify.
There’s this:
But I like the idea of that, which is the same way darktable works.
I’m fully “incompatible”!
At any rate, I tried toggling all these options (restarting in between) and it made no difference. It’s no biggie, just a curiosity.
Thanks.
I really didn’t know either but it seemed like a funny suggestion and appropriate for a slow down
I found only one post referencing Lazy Caching and it was just Alberto recommending someone disable it (and another option) to work around a particular issue.
No further enlightenment… that’s me, searching for enlightenment!! LOL 
It might be exiftool – on windows it’s particularly expensive to run. You can try disabling it by clearing “Preferences → Image Processing → Exiftool command” and see if that makes a difference.
Normally exiftool is run only as a fallback if exiv2 can’t decode the metadata properly. If this happens, maybe you can share one of your raw files so I can take a look…
Oh, I can reproduce, but only with CR3.
You can see ARW and NEF are selected instantly, CR3 with lag.
Didn’t recognize as those are not my own photos… So, just switch your camera system 
most likely this is exiftool – I have to investigate why it gets called, maybe I miscompiled exiv2
Yeah, exiftool is Perl, right? That means it’s gotta compile to bytecode first (IIRC) and that’s slow on Windows. Anyway, without it there’s no EXIF at all - Zilch. Several images remained black in the browser until I deleted all sidecars, now they’re OK - Just no EXIF.
Here’s a sample CR3:
Uploading: IMG_1692.CR3…
Thanks.
Check’s in the mail, I presume? 
Maybe… we see what Alberto will find out first 
Gaaned’s build doesn’t lag, which I guess confirms Alberto’s suspicion.
I’m not sure it’s because it’s Perl or simply because spawning subprocesses is slow on windows – or a combination of both. Anyway:
ok, so I might have miscompiled exiv2. I’m rebuilding right now, let’s see…
I have uploaded a new version of the windows installer (1.16.4.1, just to distinguish it from the previous one), hopefully it fixes the problem…
It does for me. Thanks
Unchanged here (no EXIF), but I’m not sure if all went properly.
I downloaded this…
…which is this…
…and says this in Control Panel…
But when I run it, Preferences | About | Version says this…
I don’t know if the missing minor number matters, but the commit date is two weeks ago…
???
I totally uninstalled / reinstalled, too.
Did you revert your config? (I mean the Exiftool command)
Also, did this version pick up the other things you’ve changed (e.g., single click folders, etc.) or is that a different branch? No change on that, either.
I left the exiftool field empty, so exiv2 will do it instead…
Wait a minute, this is weird. I’m getting EXIF in some folders, but not in the one I was testing. Let me poke around and report back…
OK, so apparently I had to clear cache One More Time… working now. Weird but I’ll take it. It’s also recognizing my Sigma lens properly now! Woo Hoo! I assume the other commits are a different branch which will make it into the next “full” release.
Thanks for the assist.
Yes, it’s “just” a new build of the current release. I gues that no commit was made, but just a fix while compiling. Therefore the version info hasn’t changed.