In our office, we use UNC paths to point to yak packages saved on the company server. This leads to super long waiting times for the package manager to display available plugins:
Accessing these network drives in Explorer is instant. Any ideas on how to speed this up?
Hi Mariusz -
Not at this point, no. We have this on the list as RH-67625 (not public) and attempts have been made to find out why this is slow but no solution was found so far. I’ve added this thread to the issue report.
-wim
Hi @wim, did you make any progress on this issue? It’s killing us internally, especially when users are on a VPN.
Alternatively, do you have other suggestions on how to distribute private Rhino/GH packages across an organization?
Hi Mariusz -
I’m told that the speed will depend on the number of packages that are available on the server. This is not only the number of different packages that are published, but also all previous versions of a given plug-in that are still available. The only solution for the time being is to try to limit this total number of packages.
CC: @fcegnam - not sure if the two of you have different servers or are using a common one.
-wim
Hi Wim,
ah, I’ve found the root cause. I suspect that the Package Manager searches for yak files in subfolders as well. We have a 30GB+ dataset with thousands of files located under the same directory and it was bringing the PM to a crawl:
Moving all yak files to a separate location fixes this.
Thanks for looking into it!
PS @fcegnam uses the same server.