P: SDK: LrTasks.yield is *extremely* slow on Windows

So, fixing the event loop timer *did* fix the grid scrolling? Or, does that remain to be seen?

Funny you should mention that just now. I was just discussing today with somebody that very possibility. I find the grid hitchy on the Mac as well, but since grid scrolling and thumbnails involve a lot of inter-thread communication it could definitely be impacted by the timer. It turns out that fixing the event loop timer issue didn't require as much nudging as I originally expected anyway (there's already a fix in the works).

Dan, you wrote "if I can find a case where it's causing a significant performance deficit (that isn't resolved by reducing yield frequency a bit, which is probably better anyway), I think it'd be possible to implement a higher precision approach for the next major rev.".

Sorry if this is a complete miss, but is there any chance that the mediocre grid scrolling performance in the Library module" (on Windows only?) is caused by the yield timer resolution issue?

It appears that (at least partially) the display of image decorations (badges, etc.) causes the slow down and if these are applied in a loop which contains a "yield" this may have a negative impact?

I feel that the lack of a smooth, fluid scrolling experience in the grid mode is a significant problem.

Sorry, again, if this is unrelated to the "yield" issue.

Excellent, Dan. It is very good that you are looking into this. I've seen LR to be quite a bit snappier on Macs than on PCs (different Macs and different PCs). While it is likely that hardware differences played a role too, it would be great to eliminate a potential source for unnecessary slowdowns.

Some experiments with a plugin that uses lots of individual metadata requests (as opposed to using the batch routines) that shows the same behavior and Windows specific slowness. I've got some buy-in to get a fix for this, so there is an internal bug for it now. I suspect that change is still going to be a little too risky for a 3.x dot, but it does at least give me a good benchmark to use for confirming a fix.

Did some profiling:

LrTasks.yield() 12.4 msec average (too long)
LrTasks.sleep(.00001) 15.6 msec average (expected)

I thought maybe yield was doing same as minimal sleep, but that's not it...

I assume sleep burns one tick then waits for the next (expect 15msec & change)

If yield were just waiting for 1st tick it would take average of 5ms & change - but that's not what's happening.

Just did some profiling:

LrTasks.yield 12.4 msec average.
LrTasks.sleep(1) 102 msec average (right - no decimal point)

Yikes!

And if the dispatch loop has a 10 ms timer on Windows, then a one-way trip through the loop will take on average 5 ms, which is the difference between the Windows and Macs LrKeyword.getName(). Maybe the difference is actually caused by something else (e.g. the differential cost of file-system locking invoked by SQLite), but the internal yield sure looks suspicious.

Hmm. That seems about right as a confirmation of my hunch of where else this timer would slow things down. Any data request is going to involve some amount of inter-system messaging. When those messages are coarse grained (where the underlying operation takes significant time) the 10 ms won't be noticed. Where the operation is very fast, it'll show up as a significant (several times slower) overhead.

Checking my notes from last fall, LrKeyword.getName() takes about 6 msecs on Windows, while it takes only 1 msec on Mac. I measured other SDK methods but I can't find my notes.