Latency issues when using GhPlayer

[remy.pere]

Hello,

I experience some bugs on Rhino 8 that I can’t explain, such as delays of several seconds when using GhPlayer.

We haven’t been able to resolve the issue with McNeel so far. So I managed to isolate to the maximum the issue. Here are the steps to reproduce the bug:

• We completely uninstalled Rhino 7 and 8 (via the Control Panel, manually deleting all Rhino and McNeel folders, and cleaning the Windows registry).

• We then reinstalled the latest version of Rhino 8.

• On first use, we create a geometry (line or polysurface) and run the following script using the GhPlayer command: _-GrasshopperPlayer “C:\Users\rpere\Documents\Create Bloc.gh”
  Simplified file R8.gh (20.9 KB)

  • This script does not use any plugin components.
  • It retrieves the selected geometry and creates a block instance named gl.1. If used on multiple geometries, the number increments: gl.2, gl.3, etc.
  • At this stage, there is no noticeable latency.

• Next, we open a large script with several hundred components.

Big script.gh (5.4 MB)

*** This script also does not use any plugin components.**

• We close this script without doing anything else.

• From this point on, if we run the first script again, a delay of 2 seconds occurs after the block is created.

• Closing Rhino or restarting the computer does not remove the latency. It even persists after uninstalling Rhino 8 via the Control Panel. The only way to remove it is to manually uninstall everything

(detail: the first time the script is used in a Rhino file, after opening Grasshopper, there is no latency — it appears starting from the second use).

When checking the Task Manager, Rhino appears to use significantly more RAM after running the large script (even after restarting Rhino).

We did not experience this kind of behavior in Rhino 7. 2 seconds doesn’t seem to be a lot, but it penalize a lot our work. Could someone assist us in resolving this issue?

Here my system info :
Rhino 8 SR17 2025-3-7 (Rhino 8, 8.17.25066.07001, Git hash:master @ b14fcd901289f8715631debb308bc919a4988e07)
License type: Commercial, version 2025-03-07
License details: Cloud Zoo

Windows 11 (10.0.26100 SR0.0) or greater (Physical RAM: 32GB)
.NET 7.0.18

Computer platform: LAPTOP - Plugged in [100% battery remaining]

Hybrid graphics configuration.

• Primary display: Intel(R) Iris(R) Xe Graphics (Intel) Memory: 2GB, Driver date: 10-11-2024 (M-D-Y).*

• Integrated graphics device with 4 adapter port(s)*

•    - Windows Main Display is laptop's integrated screen or built-in port*
  

•    - Secondary monitor attached to adapter port #1*
  

• Primary OpenGL: NVIDIA GeForce RTX 3060 Laptop GPU (NVidia) Memory: 6GB, Driver date: 2-25-2025 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 572.60*

• Integrated accelerated graphics device with 4 adapter port(s)*

•    - Video pass-through to primary display device*
  

OpenGL Settings

• Safe mode: Off*
• Use accelerated hardware modes: On*
• GPU Tessellation is: On*
• Redraw scene when viewports are exposed: On*
• Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)*
• Anti-alias mode: 4x*
• Mip Map Filtering: Linear*
• Anisotropic Filtering Mode: High*
• Vendor Name: NVIDIA Corporation*
• Render version: 4.6*
• Shading Language: 4.60 NVIDIA*
• Driver Date: 2-25-2025*
• Driver Version: 32.0.15.7260*
• Maximum Texture size: 32768 x 32768*
• Z-Buffer depth: 24 bits*
• Maximum Viewport size: 32768 x 32768*
• Total Video Memory: 6 GB*

Rhino plugins that do not ship with Rhino

Rhino plugins that ship with Rhino

• C:\Program Files\Rhino 8\Plug-ins\Commands.rhp “Commands” 8.17.25066.7001*
• C:\Program Files\Rhino 8\Plug-ins\rdk.rhp “Renderer Development Kit” *
• C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp “Rendu de Rhino” 8.17.25066.7001*
• C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.17.25066.7001*
• C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp “Snapshots” *
• C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp “MeshCommands” 8.17.25066.7001*
• C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.17.25066.7001*
• C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.17.25066.7001*
• C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse” *
• C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp “Displacement” *
• C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp “SectionTools”*

[remy.pere]

Hi, I found where the problem is. Surely you’ll can do something with it !
It belongs in the “grasshopper_mru.xml”

I explain

1. When I install Rhino, the folder C:\Users\rpere\AppData\Roaming\Grasshopper looks like this

2. I open Rhino and launch the small script with ghplayer
   → Nothing change

3. I launch the big script (without gh player)
   → Nothing change

4. I close it
   

   
   
   → a new xml file appears

=> the latency appears already

5. I close rhino, the folder looks like this
   
   
   
   → 4 xml files are created

If I open rhino and try the ghplayer scrip, latency still here

6. I close Rhino, delete “grasshopper_mru.xml” file, open it and launch the ghplayer
   => latency is gone

[kike (Kike Garcia)]

Thanks this helps a lot!

[remy.pere]

Hello,

You’ll found here some new insights that may help clarify the issue.

While we wait for a concrete solution, I’ve implemented a workaround that partially addresses the problem:
A script runs automatically when Rhino starts and deletes the Grasshopper MRU (Most Recently Used) file.
=> As a result, the latency caused by GH Player does not persist between Rhino sessions anymore.
(The downside is that we lose the recent file history, but that’s not a problem for our users.)

However, this does not fix the issue when a large Grasshopper file is opened during the same session:

1. I launch Rhino (MRU is deleted via script).
2. I run a small GH Player script → no lag.
3. I open a large Grasshopper file and then close it.
4. I run the same small GH Player script again.
5. => Rhino freezes for a couple of seconds. The lag remains until Rhino is restarted.

It seems that after each GH Player execution, Rhino/Grasshopper performs an internal operation related to recent files, which causes a short freeze — possibly due to memory references or caching.

Additionally, if I make two copies of the large script and open/close both within the same session, the freeze duration doubles (and triples with three copies, etc.). That’s why it can be impossible to work this way after a few hours using several programs.
This indicates some sort of accumulating memory footprint or resource tracking that doesn’t clear when closing a GH file.

I join here the scripts again :

1. small script to run with gh player
   Simplified file R8.gh (20.9 KB)
2. Big script to open and close only (to copy if we want to see the double duration freeze
   Big script.gh (5.4 MB)

Hope you’ll can do something soon !
Regards

[kike (Kike Garcia)]

Hi @remy.pere,

This will be fixed on next 8.20 RC.

[remy.pere]

Hi @kike

Thanks for the update !
Since you’re now working on 8.19 RC, we can imagine it will take 1 or 2 month ?

[Japhy]

The 8.19 will be released early next month with 8.20 becoming the RC until early June.

We can send you a early daily build for testing, but if you are looking to deploy company wide I would wait until the 8.20 at least gets to Release Candidate status.

[remy.pere]

Hi @Japhy
Sure, I asked to be sure, and so that we could organize ourselves accordingly.
But yes, if you can send me a built for testing it could be great !

Thanks

[Japhy]

I’ll send you a 8.20 tomorrow, the fix might not be in today’s build.

[remy.pere]

Perfect, don’t worry I wont work on it today

[remy.pere]

Hi @Japhy can you send à 8.20 as you said ?
Thanks

[Japhy]

Sent, and thanks for reporting back a successful fix (via PM)