906 x64 : high latency in listing folder content upon large media files (video)

[kino]

Hello,

Weird perf. behavior I've been encountering since build 906 (and now 908) :

On folders containing large media files (like .mp4, .mkv, etc.) listing a few dozen files can take 10 seconds whereas it won't take one sec with hundreds of non-media/small files.

I can't swear my Windows 11 OS hasn't changed a bit since I used build 904 (because of upgrades & patches) but Windows Explorer on the same folders doesn't behave like that (fairly quick to list media).

I've given a try with procmon (from Sysinternal Suite) and it looks like FreeCommander is generating 10 times more filesystem events (about 300 per file) upon those files than explorer.

Should I disable something in FreeCommander ?

Thanks

[Forez]

Have you tried downgrading to previous versions? Does this issue prevail in them on the very same operating system?

[kino]

Hello Forez.
Not only did I reverse to 906 but went back to 908 and 910 and it doesn't happen any more.
I HAD restarted several times my Win11 so it was not some kind of dumb blocked interrupt stack or yet unapplied update.
Geez ; I'm happy it's gone and though I feel helpless with that kind of perf/latency behaviors.
Anyway, thanks for your reply.
Consider this solved (until resugence)
K.

[kino]

Well, resurgence is now.
I don't get what happens but I investigated a little further with Sysinternals/ProcMon and I figured out that every time FreeCommander is activated, any media file (.mkv, .mp4, etc.) in both panels is issued a IRP_MJ_FILE_SYSTEM_CONTROL operation (FSCTL_REQUEST_OPLOCK control) that ends up being CANCELLED (probable timeout) after 0.1 second which is HUGE compared to other events on all files (about a thousand times quicker).
With a few dozens of media files, I can wait for several seconds between each click.
It's not related to the size of file : that IRP_MJ_FILE_SYSTEM_CONTROL operation is not issued on other types of files, even as large.
I've tried to disable thumnails generation but it didn't change anything.
Nothing to do with AntiVirus either ('keeps happening when disabled)
...and still, Windows Explorer doesn't cause that.
Does any Windows-savvy user of FC knows what could be the problem ?
Thanks !

[kino]

...well I managed to figure out in the top frame of stack that some mini filter would cause latency and had been registered by AVG at a pretty hight altitude :

Code: Select all

# fltmc

Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
avgSP                                   8       388431         0
PROCMON24                               9       385200         0
avgMonFlt                               8       320730         0
avgSnx                                  8       137630         0

So I ditched AVG ('cuz there's no way I'd get rid of good'ol' FC )
Still, FC is doing something that Windows Explorer doesn't at some point since those FSCTL_REQUEST_OPLOCK do not occur (and obviously, AVG won't test the behavior they can cause further than native system tools)
'hope it'll help anyone encountering the same problem (oftentimes anti virus are the culprit anyway)