Honestly not sure what the provided information can achieve. It might be a very good starting point for investigation if you were considering attempting to optimize this performance yourself. But on its own it doesn't say anything conclusive.

There is an assertion here that the "stuttering" performance experienced is related to the number of stat calls shown, but evidence that these things are connected would be found in actually profiling the code. Otherwise it seems to be just a guess from the only type of data collected. By what metric do you judge these stat calls to be too many to the point of "aggressive"? How many is the correct number?

There could be more calls to stat than is required. We might be calling it to see if a file (and the thumbnail for it) exists and then also calling it again to find the file dates or file size. But... stat calls are extremely fast and would not account for the long delays shown in your second video. To understand what is happening there requires that you load up the source and profile to see what is taking up the time. There will be something, and likely something that can be improved. But it won't be the stats.

In T101382#1423146, @Harley Acheson (harley) wrote:

Honestly not sure what the provided information can achieve. It might be a very good starting point for investigation if you were considering attempting to optimize this performance yourself. But on its own it doesn't say anything conclusive.

Just thought to attempt to raise a potential issue more than anything, sorry if this isn't the right channel for it.

There is an assertion here that the "stuttering" performance experienced is related to the number of stat calls shown, but evidence that these things are connected would be found in actually profiling the code. Otherwise it seems to be just a guess from the only type of data collected.

I'll have to admit, those are indeed guesses based on the fact, that one stores the library in a physical (thus faster) device and the other on a network (way slower) share.

I've tried to at least remove the OS factor from it and tested the same setup on two Linux devices, one connected to the other similiarly like how Windows was connected to the SMB of the Linux, with the additional difference of being linked on Wi-Fi, as opposed to being linked by cable.

The same effect has occured and the strace command showed that each stat can take up to 0.5 second, which quickly stacks up.

By what metric do you judge these stat calls to be too many to the point of "aggressive"? How many is the correct number?

As in the second part of the first video, where the calls are counted, they have quickly reached thousands from just hovering over with a mouse. I'd assume at the very least that such information shouldn't really be needed to be accessed from the filesystem again so often and so it'd be cached in memory or at least somewhere local.

As to how many is the correct number, I'd say that tens of thousands while just hovering the mouse is probably not the correct one.

There could be more calls to stat than is required. We might be calling it to see if a file (and the thumbnail for it) exists and then also calling it again to find the file dates or file size.

I understand that, but is it necessary to call it on every frame the mouse hovers over the thumbnail/asset library?

But... stat calls are extremely fast and would not account for the long delays shown in your second video.

They might be fast on local devices, but in usecases such as the asset library being shared and stored on a network share (or even a slow media storage) might pose some trouble, when the delays stack up with the amount of files.

To understand what is happening there requires that you load up the source and profile to see what is taking up the time. There will be something, and likely something that can be improved. But it won't be the stats.

Indeed, as I've said, it was just a guess and a shot in the dark. It might not be directly the stat calls, but it seems to be linked with the asset library being on a slower storage device.

I understand this kind of "unscientific" way of investigation isn't exactly the best, however I lack the resources to provide detailed analysis, so I just left it at attempting to raise a potential issue.

@Pavel Duong (vignette) - Just thought to attempt to raise a potential issue more than anything, sorry if this isn't the right channel for it

Yes, no worries. Although this doesn't "fit" as a bug report - and will probably just get closed - I will probably poke around in that code there when I get a chance.

I'll have to admit, those are indeed guesses based on the fact, that one stores the library in a physical (thus faster) device and the other on a network (way slower) share.

There are probably some other more intensive file accesses in there, like reads.

with the additional difference of being linked on Wi-Fi, as opposed to being linked by cable.

Yes, there will lots of performance bottlenecks if connecting to a file share over a slow connection like wifi. Especially creating thumbnails of files since that requires reading the entirely of each file to make each preview.

...but is it necessary to call it on every frame the mouse hovers over the thumbnail/asset library?

To answer that you would have to know about the internals of that code.

...but in usecases such as the asset library being shared and stored on a network share (or even a slow media storage) might pose some trouble, when the delays stack up with the amount of files.

For sure, but in this case it will be other file activity, like accesses and reads that will contribute to most of that time, not the stats.

...however I lack the resources to provide detailed analysis, so I just left it at attempting to raise a potential issue.

No worries. I really do appreciate the attempt to help. But this requires that someone else do the actual profiling to find the root of the issue and then improve it. This just doesn't fit within this system of bug reporting.