Logos 8.4: Very frustrated at how long it takes for Logos to wake up from idle

This has been a problem for a long time, but I'm only now just reporting it. I'm running Windows 7 on a pretty fast machine.

If Logos has been up and running but is not the active app, and has been idle for some time, and I switch back to Logos from whatever else I was doing, it takes a really long time before Logos is responsive to my mouse or keyboard input.

For example, if I Alt+Tab from another app back to my floating Library window in order to type in a title and see if I have it, I have to wait a full 10 seconds before Logos stops spinning its "busy" wheel.

Here's the relevant excerpt from the log file:

2019-04-26 18:03:41.2118 1 Info LDLS4.AppModel App is now idle.
2019-04-26 19:36:09.5812 1 Info FloatingWindow Floating window activated: LDLS4.FloatingWindow
2019-04-26 19:36:09.6092 1 Info LDLS4.AppModel App is no longer idle.
2019-04-26 19:36:09.6182 20 Info SyncManager Requesting sync on all sync clients
2019-04-26 19:36:19.2837 1 Info FloatingWindow Floating window activated: LDLS4.FloatingWindow

So the culprit seems to be SyncManager Requesting sync on all sync clients.

I can see why it's important to check for anything that needs to be synced when you activate the app again after it's been idle for a while. You might have done something in Logos on one of your other devices in the intervening time and this instance ought to get updated. But it's really bad to have to wait 10 seconds to get a response from an idle app when you activate it. I know of no other app that has such a slow response time. Reactivate Word or Outlook and they are awake and responsive instantaneously.

There must be a better way to do this.

Users are, in general, slow in interacting with software, way slower than the software can be at doing computation. So you can get a lot of stuff done in the pauses between when the user is thinking about what they're going to do next. Don't start trying to do that when the user is typing, though. That's when you need to be really snappy. Use your idle loop for doing housekeeping tasks and hitting the network. If the user issues a command that requires up-to-date info that you haven't had a chance to update yet (such as that everything be sync'ed), update it after they hit Enter or click the button that starts the command churning, not before you listen to their keystrokes. This is a fundamental principle of Windows programming (and Mac too, I presume). A user will be much more forgiving if you have to spend 10 seconds doing some preliminaries after they've typed/clicked because they consider it to be part of the processing time.

But really, if I'm viewing the Library, what needs to be synced before you can display what I've searched for? If I have a bar across the top saying the Library is being update (and thus my filtered results might not be accurate) that's one thing. But not even being able to do a quick search for a book and have it work in a couple of seconds when I Alt+Tab back to my Library from wherever is really unpleasant.