Lag on Finder when using odrive

Tony, I just sent my diagnostics.

  • Matt

Hi @prestonjohnlewis and @matt2,
Thanks for sending those.

I took a look at the diagnostics and I the majority of what is being seen is due to the scale of the data. You both have between 650,000 and 700,000 objects that odrive is actively tracking both on the local and the remote side.

The more data that odrive has to track , the more overhead it will accumulateas it tries to maintain state on each object. This overhead will carry into pretty much every operation, including FinderExtension activity.

Unsyncing unused or little-used sections of data can mitigate this (the degree of help correlates to how much is removed from odrive’s scope). Is this an option?

Possibly but is there any other solution? Does oDrive2 have better ability to handle that number of objects without lag? Why is it fast on windows oDrive but slow on Mac?

  • Matt

Hi @matt2,
The underlying code for the odrive stuff is the same on both platforms, but there may be something in the Finder Extension framework/implementation that causes a slowdown at scale. I’ve put this on my list for further investigation to see if there is anything that can be done to improve performance, but I’m not sure when I’ll get a chance to really dig into it.

Ok, so then what type of storage amount is oDrive optimized for?

i’ll also note I’ve used oDrive for a long time and it seemed to keep up with the large amount of files I’ve been syncing. It wasn’t until this year that I really started to see the heavy load placed on the computer.

Okay, for now I will just uninstall oDrive from the MAC because it is unusable. It is interesting that the problem does not exists on the PC…

Matt

There are several factors that contribute to performance, so we don’t really have an exact number for optimal use. Most users are tracking less than 100,000 objects per system and you will typically start to see a noticeable performance impact after a few hundred thousand objects. The QA team uses a data set that is around 200,000, across the various storage sources.

We will need to dig into the lower-levels of the Finder integration to see if there is anything that can be done to optimize for larger data sets.

Update
Our latest versions have optimizations for Finder integration that resolves latency and high CPU