Rhino 6 Beta Mac Grasshopper performance

Serengeti (Rhino 8 BETA) Mac
1

Is it still too early in the development process to be talking about performance in Rhino 6 Mac Grasshopper? Or maybe there’s something obvious that I’m missing. I’m seeing a big speed difference in real world examples so I did this simple test:

rhino6betagh
rhino6betagh.png970×846 234 KB

rhino5gh
rhino5gh.png970×846 159 KB

Rhino 6 SR16 2019-5-29 (Public Build, 6.16.19149.14184, Git hash:master @ 4fc833d0327c4abafa141272723124c0cdfba738)
License type: Beta, build 2019-05-29
License details: Stand-Alone
Expires on: 2019-07-13

Apple Intel 64-bit macOS Version 10.14.5 (Build 18F132) (Physical RAM: 8Gb)
Mac Model Identifier: iMac18,3
Machine name: Jack iMac
Language: en-GB (MacOS default)

AMD Radeon Pro 580 OpenGL Engine (OpenGL ver:4.1 ATI-2.9.26)

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: Height

Vendor Name: ATI Technologies Inc.
Render version: 4.1
Shading Language: 4.10
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 8 GB
Graphics: Radeon Pro 580
Displays: iMac (217dpi 2x)

Graphics processors
Radeon Pro 580 (8 GB)
iMac (2560 x 1440)

USB devices
Broadcom Corp.: Bluetooth USB Host Controller
Apple Inc.: FaceTime HD Camera (Built-in)
HGST: G-DRIVE mobile USB-C

Bluetooth devices
Broadcom: Magic Keyboard with Numeric Keypad
Broadcom: Magic Mouse 2

Third party kernel extensions
None

Third party plugins
/usr/lib/log/liblog_network.dylib

Rhino plugins
/Applications/RhinoWIP.app/Contents/PlugIns/PanelingTools.rhp “PanelingTools” 6.16.19149.1002
/Applications/RhinoWIP.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoDLR_Python.rhp “IronPython” 6.16.19149.14184
/Applications/RhinoWIP.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/Commands.rhp “Commands” 6.16.19149.14184
/Applications/RhinoWIP.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/GrasshopperPlugin.rhp “Grasshopper” 6.16.19149.14184
/Applications/RhinoWIP.app/Contents/PlugIns/Displacement.rhp “Displacement” 6.16.19149.1002
/Applications/RhinoWIP.app/Contents/PlugIns/RhinoRender.rhp “Rhino Render” 6.16.19149.1002
/Applications/RhinoWIP.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RDK_EtoUI.rhp “RDK_EtoUI” 6.16.19149.14184
/Applications/RhinoWIP.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCycles.rhp “RhinoCycles” 6.16.19149.14184
/Applications/RhinoWIP.app/Contents/PlugIns/NamedSnapshots.rhp “Snapshots” 6.16.19149.1002
/Applications/RhinoWIP.app/Contents/Frameworks/RhMaterialEditor.framework “Renderer Development Kit” 6.16.19149.1002

2 Likes
2

Absolutely not. Now is the time! Thanks for this. Can you please save us another 5 minutes and attach this definition?

3

The definition is attached. Also two activity monitor screenshots. The bumps to the right of the cpu timeline correspond to me repeatedly hitting ‘Recompute’ with this definition running in Rhino 6 beta. During this period I saw Rhino’s entry in the %CPU column hitting about 60% max. The memory screen shows the same time period.

This same definition in Rhino 5 + Grasshopper uses about half the memory and about half the max CPU.

Not very scientific but maybe it will help.

01
011074×930 110 KB

29
291074×930 119 KB

speedtest.gh (7.3 KB)

1 Like
4

Thanks @purchase. I see this and I logged it in RH-53015.

As you might know, about a year ago, we made some major changes to Grasshopper in Rhino 6 for Mac. This brought the Windows and the Mac codebases for Grasshopper much closer together…we may have inherited this new (old) performance. Until we dig in deeper, this is pure speculation.

@DavidRutten Does any of the above ring a bell? I don’t know why we’d see performance slowdowns across the board, but maybe there was a major change I don’t recall that got picked up in the VB.NET conversion.

cc: @curtisw

5

Thanks @dan. Glad to hear I’m not going completely mad :slight_smile:.

1 Like
6

I’ve been keeping an eye on the issue tracker and I’m a little concerned that this one may get stuck on the ‘too difficult’ pile. My real-world examples take 3 or 4 times as long to recompute. The worst case is taking 9 seconds in Rhino 6/7 as compared to 3 seconds in Rhino 5. The slowdown is spread across almost all Grasshopper components so it’s hard to optimise when there’s no real bottleneck.

More generally, well done guys for keeping Rhino 7 development going at all despite Covid-19!