Memory Leak with Layouts

I’ve noticed that the RAM usage increases when I work with layouts. Below, I’ve recorded a short, admittedly somewhat boring, video that shows the memory filling up simply by activating the different layouts.
In the video, you can see that I start at 18.5 GB of RAM, and after about four minutes of clicking through the layouts, I end up at around 27 GB. The RAM doesn’t increase further. After closing and reopening the Rhino file, it’s back to 18.5 GB.

There was already a post describing the same problem: Memory Leak in Layouts?

Unfortunately, I can’t share the Rhino-file.

@dan, I hope that you are the right person to tag here.

Here is my System Info:

Rhino 8 SR19 2025-4-22 (Rhino 8, 8.19.25112.13001, Git hash:master @ 0fe5f551e3e34ca51834ba0ca2217647d8027942)
License type: Commercial, build 2025-04-22
License details: Cloud Zoo

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

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

Non-hybrid graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 4070 Laptop GPU (NVidia) Memory: 8GB, Driver date: 10-15-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 566.03
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port
Primary OpenGL: NVIDIA GeForce RTX 4070 Laptop GPU (NVidia) Memory: 8GB, Driver date: 10-15-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 566.03
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port

Secondary graphics devices.
Intel(R) Iris(R) Xe Graphics (Intel) Memory: 1GB, Driver date: 6-15-2023 (M-D-Y).
> Integrated graphics device with 4 adapter port(s)
- Secondary monitor is laptop’s integrated screen or built-in port

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: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 10-15-2024
Driver Version: 32.0.15.6603
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 8188 MB

Rhino plugins that do not ship with Rhino
C:\ProgramData\McNeel\Rhinoceros\8.0\Plug-ins\Datasmith Rhino Exporter (d1fdc795-b334-4933-b680-088119cdc6bb)\DatasmithRhino8.rhp “Datasmith Exporter” 5.5.3.0
C:\Users\simon\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\NVIDIADenoiser\0.4.3\NVIDIADenoiser.Windows.rhp “NVIDIADenoiser.Windows” 0.4.3.0
C:\Users\simon\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\Bullant\24.12.10.8\bullant.rhp “bullant” 24.12.10.8
C:\Users\simon\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\ggRhinoIFC\25.4.29.8\ggRhinoIFC.rhp “ggRhinoIFC” 25.4.29.8

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp “Commands” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\RhinoRender.rhp “Legacy Rhino Render”
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.19.25112.13001
C:\Users\simon\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\PanelingTools\2024.8.20.677\PanelingTools.rhp “PanelingTools”
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp “MeshCommands” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\IronPython\RhinoDLR_Python.rhp “IronPython” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 8\Plug-ins\BlockEdit.rhp “BlockEdit” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp “SectionTools”

1 Like

Hi Simon-

Thanks for reporting this!

That video is quite instructive. I like how you switch back to perspective - it does drop a bit :grimacing: - and then go back to the layouts and it climbs again from a higher plateau. That definitely looks like a memory leak.

Would it be possible to share the file privately via our secured upload page? If you can, please add dan@mcneel.com to the recipient address. I’m speculating here, but I’m guessing we’ll likely need the file to reproduce this - but perhaps I’m wrong. Regardless, I thought I’d check.

-Dan

1 Like

Done. Thanks for looking into this.

1 Like

Thanks! Files in hand. Much appreciated. It will be kept confidential and deleted as soon as possible. I’ll take the next steps and see if we can reproduce this here. I bet we can.

1 Like

I’ve been attempting to reproduce this here and I’m not able to so far (I had such high hopes). Regardless, it may be something I’m doing wrong, so I’m going to create an internal bug track item and see if someone smarter than I can detect a leak in the profiler.

That said, I do notice from your SystemInfo that you have some plugins installed. Though it’s not likely, I do wonder if one of those might be implicated. You might try disabling those plugins, restarting Rhino and seeing if the leak still occurs (or not.) If not, that would be very useful information as we might be able to isolate which one.

1 Like

Hi Dan,

I work on the same project with Simon and we just ran a few additional tests on the same file. Here are a few observations we made:

  • Except from GeometryGym I don’t have the additional Plugins installed he has on his machine. I disabled GG on my machine and it doesn’t change any of the effects we’re talking about here.
  • We realized that Simon ran his tests on his office setup with a 4k screen attached. I only have a 2k screen at hand and encountered a similar increase in Ram usage as he did but at a much lower rate. So I enlarged the Rhino screen to fit both the stationary Screen and my Laptop Display (I wor on a laptop with an external screen in Windows multiple-screen mode) and by that I could fake a Viewport size of 3257 x 1732 Px (measured via ViewCaptureToFile :slight_smile:
    Now when flipping through the Layouts I see a similarily steep Ram increase as Simon documented in his Video filling up the 32 Gigs of Ram after roughly 2/3 of the Layouts.
  • Then I stopped and didn’t do anything for a few minutes and the Ram usage went down to something around 26 GB but not further. When Closing Rhino and restarting it it’s back to around 15 GB..
  • I flipped through all the Layouts a second time filling up the Ram again and when it was full I deleted all the Layouts. Ram immediately went down to 15 GB (back to where it was when starting up the file.
  • It felt like some pixel-based information was cached on the Layouts and as we only have a (rather big) Wireframe-Detail all over the Layout (clearly Vector-based) we suspected the 3D-Detail with the Rendered Display Mode could be the issue. We switched the Rendered DP-Mode of that Detail to a Shaded one in all Layouts and had a similar increase in Ram usage. Bummer.
    So we went down the full cascade.. Switching to Wireframe Display-Mode on all Details, deleting 3D-Details, deleting all Details, deleting all Geometry on the Layout Views, deleting all Geometry in the entire file, purging the entire file - each time trying what happens when flipping through the layouts..

So now we are here with an empty purged file with 58 rather big Layouts. When flipping throgh those Layouts in a rather big Viewport (around 4k) our Ram still fills up until on the last Layout hitting the 32 GB limit, resting there for a few moments and then falling back to around 26 GB. It remains there until either Rhino is closed or the Layouts are deleted.

Here is the emptied out file:
PurgedEmptyFile.3dm (167.1 KB)

Is this something you can reproduce on your machines? It still looks like if there was some pixel-based info cached somewhere on each Layout but it’s quite strange to have such a cache in a completely empty file - or are we missing something there?

Sorry for the wall of text, just tried to be accurate and report everything we see here :slight_smile:
We hope you are able to get a step further with this information..

We’ll also continue testing on our different machines..

Best
Romuald

2 Likes

Hi Romuald-

This is all really valuable information…truly thorough testing. I think you suspicions are well-founded. I’ll test this out tomorrow. I have a 5k display I can test with so we can see if I can trigger this behavior.

-Dan

3 Likes

Hi Dan,

I have another observation that might be interesting in that context:

I’m at work now where I have another machine with a fresh Rhino installation. I tried to open a new empty file and created 100 A0 landscape Layouts in it. Then I did the same trick as yesterday on the laptop and enlarged Rhino over two 2k screens to get roughly the surface of a 4k screen and flipped through those empty Layouts.
While doing that the memory raised from initially 10 GB to finally roughly 40 GB, falling back to 10 when closing Rhino.

Very curious to hear if this is reproducable on your 5k Display..

2 Likes

Hello Simon and Romuald!
For good measure, could you update your video card driver to the latest version? While I’m not sure this is the cause, it will help to eliminate that as a possible factor. I’m not sure what the other machine(s) have regarding hardware/drivers, but I noticed the system info Simon posted had an older driver version for the NVIDIA GeForce RTX 4070.

1 Like

Hi @romio82,
Despite your incredible instructions, files, fonts and display mode and similar computer systems, we can not get the memory usage to spike. Memory does not get much higher than this graph:

It bumps up a slight amount when PrintPreview is enabled ( -_PrintDisplay and set it to enabled) and we pick to activate each of the 50 or so layouts.

We would like you to simplify your system for testing.
In Options → Plugins, disable all the plugins that do not ship with Rhino.Restart.
Rhino and test.
Rhino plugins that do not ship with Rhino

  • C:\ProgramData\McNeel\Rhinoceros\8.0\Plug-ins\Datasmith Rhino Exporter (d1fdc795-b334-4933-b680-088119cdc6bb)\DatasmithRhino8.rhp “Datasmith Exporter” 5.5.3.0
  • C:\Users\simon\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\NVIDIADenoiser\0.4.3\NVIDIADenoiser.Windows.rhp “NVIDIADenoiser.Windows” 0.4.3.0
  • C:\Users\simon\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\Bullant\24.12.10.8\bullant.rhp “bullant” 24.12.10.8
  • C:\Users\simon\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\ggRhinoIFC\25.4.29.8\ggRhinoIFC.rhp “ggRhinoIFC” 25.4.29.8

Also do this for testing:

  • Update your display driver (Download The Latest Official GeForce Drivers)
    GeForce Game Ready Driver - WHQL Driver Version: 576.28 - Release Date: Wed Apr 30, 2025 or NVIDIA Studio Driver - WHQL Driver Version: 576.02 - Release Date: Wed Apr 16, 2025
  • Plugin your computer to power. (Computer platform: LAPTOP - Plugged in [80% battery remaining])
  • Unplug any usb hubs or 2nd displays for testing.

Then send us a new SystemInfo so we can see if the updates were applied successfully.

Thanks for your help.
Sincerely,
Mary Ann Fugier

2 Likes

Dear @mary, @Matt_Bennett and @dan,

I updated graphics card drivers and disabled all plugins that don’t ship with Rhino, as requested. I can still observe that the RAM is filling up and that the screen resolution seems to be the crucial factor.

Video 1:
Only laptop screen (2560x1600), no second screen. Almost no filling up of RAM (12,3 GB > 13,8 GB)

Video 2:
Only secondary screen (3840x2160) > RAM filling up (14,7 GB > 24,0 GB)

Can you reproduce this on your 5k screen, @dan ?

Updated System Info here

Rhino 8 SR19 2025-4-22 (Rhino 8, 8.19.25112.13001, Git hash:master @ 0fe5f551e3e34ca51834ba0ca2217647d8027942)
License type: Commercial, build 2025-04-22
License details: Cloud Zoo

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

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

Non-hybrid graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 4070 Laptop GPU (NVidia) Memory: 8GB, Driver date: 4-27-2025 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 576.28
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port
Primary OpenGL: NVIDIA GeForce RTX 4070 Laptop GPU (NVidia) Memory: 8GB, Driver date: 4-27-2025 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 576.28
> Integrated accelerated graphics device with 4 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port

Secondary graphics devices.
Intel(R) Iris(R) Xe Graphics (Intel) Memory: 1GB, Driver date: 6-15-2023 (M-D-Y).
> Integrated graphics device with 4 adapter port(s)
- Secondary monitor is laptop’s integrated screen or built-in port

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: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 4-27-2025
Driver Version: 32.0.15.7628
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 8188 MB

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.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\WebBrowser.rhp “WebBrowser”
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 8\Plug-ins\RhinoScript.rhp “RhinoScript”
C:\Program Files\Rhino 8\Plug-ins\IdleProcessor.rhp “IdleProcessor”
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\RhinoRender.rhp “Legacy Rhino Render”
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.19.25112.13001
C:\Users\simon\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\PanelingTools\2024.8.20.677\PanelingTools.rhp “PanelingTools”
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp “MeshCommands” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\IronPython\RhinoDLR_Python.rhp “IronPython” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 8\Plug-ins\BlockEdit.rhp “BlockEdit” 8.19.25112.13001
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp “SectionTools”

1 Like

Hi @mary, @Matt_Bennett , @dan,

thanks for your investigations! As Simon did, I also followed your instructions, did another couple of tests and made a few new oservations I would like to share. Hopefully this helps identifying the problem.

I also disabled all external Plugins on my Rhino Installation and updated Nvidia Drivers to the latest version. Here is my SystemInfo: SystemInfo.txt (2.5 KB)
PrintDisplay is always toggled off.

I wrote a small script that creates 100 A0 Layouts if no existing Layouts are found or else flips throgh the existing ones. The flipping process only seems to work when the Layout panel is visible though: FlipLayouts.py (1.1 KB)

Here’s a video of me letting the script run with the Rhino Window scaled to different sizes. I recorded that video on a two-screen-setup with Screen 1 (1920 x 1200) and Screen 2 (2560 x 1440) diagonally placed to have a virtual full screen somewhere around 4k:

I did the same tests on the Laptop screen alone and my findings are still visible although less pronounced. I think this is a sign that these issues are dependant on the resolution the LayoutView is visible in.

Here’s the video, a description of what I do in that video follows below:

I start with a new empty Rhino file. I let the script run once to create 100 A0 sized Layouts. Nothing happens memory-wise.
Then I let the script run a second time and it flips through those Layouts it created before. The flipping process is recognizable when watching the TextEntity the script placed on each Layout with it’s name: It counts up from 0 to 99. Memory raises from around 12.5 GB to around 15.9 GB.

I resize Rhino’s Window and make it quite a bit smaller. I let the script run again, it flips through the Layouts and memory usage decreases to something around 13.8 GB.

Then I enlarge the Rhino Window to occupy more or less both of my screens. It now has a Viewport Resolution of 3326 x 1877 Px:


Half of its Viewport isn’t visible on the video as it only captures one of my screens but I can see it on my Laptop screen to the left :slight_smile:
When runnig the script again, RAM usage explodes and quite soon hits the maximum of somewhere around 31.2 GB. Of course the whole system feels laggy and slow. In that state, the only way to free my memory again would be to delete all the Layouts or close and reopen Rhino. (When doing that, everything is supper laggy and slow. Quite often, Rhino becomes unresponsive whene deleting Layouts or even when it’s closed, the only solution seems to be to kill it’s process via Windows TaskMager.. :grimacing:)

There is a third possibility to free the memory though, and I’m showing it in the video: I resize Rhino’s Window and make it small again. If I now let the script run again, memory is set free and goes down to somewhere around 14.3 GB.

I think these tests (together with Simon’s manual ones) show that some resolution-dependant information is cached on those Layouts and only set free when closing Rhino or deleting/updating the Layouts. Maybe this is expected behaviour but when working with lots of Layouts on high-resolution screens it is very tiring to restart Rhino every hour or so..

I hope you are able to reproduce these effects on your machines with these additional informations.. Very curiuos to hear your findings..

2 Likes

Sorry for the delayed reply. I don’t know yet. My native Windows laptop wasn’t up-to-snuff for my 5K display and I don’t trust my results in my Parallels VM, so I enlisted the help of others at McNeel. I think you’ve provided ample evidence and even some very telling clues as to where to look… we just need to reproduce it.

There is another path forward, which is to see if profiling detects anything in debug…a step we’ve not yet had time to take.

I have logged a bug-track issue (RH-87243) so that it doesn’t slip off our radar - but the issue is not public by design.

2 Likes

FYI only, I modified:

RH-87243 Memory Leak: Layouts (Reported, Unconfirmed)

so it is publicly visible (without sharing the file in question).

2 Likes