Below is a Notion-ready article version. I’ve expanded the argument into a more durable technical note, kept it readable, and added a few source-backed points where the public documentation matters.

C#, Python, Build Time, and When to Move Logic Out of the Canvas

Summary

Grasshopper scripting performance is often framed as a simple choice between C# and Python. In practice, that framing is too narrow.

The more useful distinction is between:

1. Script preparation and build time

2. Runtime solve performance

3. Import, package, and type-conversion overhead

4. Canvas-local experimentation versus maintained software

5. Individual use versus team/client deployment

C# script components, Python script components, compiled .gha plug-ins, shared libraries, and packaged tools all have different trade-offs. The right choice depends less on language preference and more on how often the logic is reused, how expensive it is to run, how many people depend on it, and how painful it would be to maintain duplicated logic across multiple Grasshopper definitions.

The Three Decision Axes at a Glance

Why This Matters

Grasshopper is often used as both a visual modelling environment and an informal software development environment.

That flexibility is one of its greatest strengths. Designers, engineers, computational designers, and developers can move quickly, prototype ideas, test geometry logic, and build project-specific tools directly inside the canvas.

But as definitions grow, the same flexibility can become a liability.

A Grasshopper definition can quietly become a distributed codebase made up of:

• Embedded C# script components

• Python components

• User objects

• Custom clusters

• Referenced assemblies

• Package dependencies

• External files

• Version-specific plug-ins

• Informal conventions remembered only by the person who built it

At small scale, this is fine. At team, client, or production scale, it becomes a maintainability problem.

The question is not simply:

Should I use C# or Python?

A better question is:

Should this logic live inside this Grasshopper file at all?

The Useful Split Is Not “C# Versus Python”

When a Grasshopper file feels slow to open or solve, several different costs may be mixed together.

The useful split is:

1. Script preparation / build time

2. Runtime solve performance

3. Import, package, and type-conversion overhead

4. Canvas versus codebase

These concerns overlap, but they are not the same. A component can have slow startup but fast execution. A script can solve quickly once cached but still make a document feel sluggish when opened. A definition can perform no heavy geometry work at all and still feel slow because it repeats lightweight setup work thousands of times.

C# Script Components Still Have a Build Cost

C# is compiled, and the Grasshopper C# script component reflects that. McNeel’s documentation notes that changes to input/output parameter combinations or type hints require the C# script to be updated and recompiled. The same documentation also states that the C# script component compiles and caches the script so it can execute faster when unchanged. (www.rhino3d.com)

That means a C# script component is not equivalent to a precompiled .gha component.

A C# script component still has to prepare, compile, and cache its script. If a Grasshopper definition contains many embedded C# scripts, those preparation costs can accumulate, especially when:

• A document is opened

• A script component changes

• Inputs or outputs are edited

• Type hints are changed

• References are updated

• The cache is invalidated

• The solver is repeatedly triggered during editing

In a small definition, this may be barely noticeable. In a large definition with many script components, the user may experience slowness before any meaningful geometry computation begins.

This is the distinction between preparing to solve and solving.

A file may feel slow not because the geometry algorithm is expensive, but because the scripting environment is rebuilding assemblies, resolving references, loading dependencies, or preparing many script components.

Python Is Not Free Either

Python is often treated as the lighter-weight option for small pieces of Grasshopper logic. That is often true in practice, especially for short scripts and quick project-specific glue.

However, Python is not free.

McNeel’s Rhino 8 Python scripting documentation states that the Python script component also compiles and caches scripts, with cache expiry occurring when the script or parameters change. It also documents support for PyPI packages, NuGet packages, package references, module search paths, virtual environment directives, and assembly references. (www.rhino3d.com)

That flexibility is powerful, but it has a cost.

A lightweight Python script that only touches RhinoCommon may feel instant. A Python script that imports scientific libraries, resolves package references, uses external modules, or moves large amounts of data between Python and .NET can introduce noticeable overhead before the actual algorithm begins.

There is also a difference between execution cost and environment cost.

In many workflows, the expensive part is not the algorithm itself. It may be:

• Importing modules

• Resolving package dependencies

• Initialising external libraries

• Converting data between Python and .NET types

• Rebuilding execution state

• Repeating setup work across many component calls

This is why legacy IronPython can still feel surprisingly fast for small RhinoCommon glue scripts. It stays close to the RhinoCommon/.NET world and avoids some of the Python 3 package and marshalling overhead. It lacks access to the broader modern Python ecosystem, but for lightweight utility logic it can still be highly responsive.

Access Type Matters More Than People Think

In Grasshopper, access configuration can have a major effect on performance because it changes how often component logic is invoked.

If an operation is meant to happen once over an entire list or tree, the inputs should be configured accordingly. If the component processes item-by-item instead, the script may repeat setup, import, conversion, or execution work many times.

This becomes especially noticeable when scripts:

• Perform imports

• Initialise external libraries

• Convert geometry types

• Allocate large temporary data structures

• Resolve package references

• Call external APIs

• Process large geometry trees item-by-item

A definition that feels slow may not be doing expensive computation. It may simply be repeating cheap work thousands of times.

That distinction matters.

Before replacing Python with C#, or C# with Python, check whether the component is being called at the right level of granularity.

A Practical Decision Tree

Use scripting components when they help you move quickly. Move logic out of the canvas when it becomes stable, repeated, expensive, or shared.

Where Should the Logic Live?

One-Off Project Glue

Use a Python or C# script component.

This is appropriate when the logic is specific to one file, one study, or one project. The cost of formalising it into a plug-in is probably not justified.

Quick Prototyping

Use a script component until the idea stabilises.

Script components are excellent for exploration. They let you test logic quickly without committing to API design, packaging, versioning, or deployment.

Instanced Across Multiple Definitions

Move the shared logic into a library or plug-in.

If the same script appears in multiple Grasshopper files, it is no longer just a local script. It has become shared logic. At that point, duplication creates risk.

A bug fix may need to be applied in several places. Different files may contain slightly different versions. Nobody may know which version is canonical.

Moving the logic into a shared implementation gives you one source of truth.

Computationally Heavy / Called Repeatedly

Prefer compiled C#/.NET.

For geometry processing, data transforms, meshing routines, analysis workflows, or operations inside tight loops, compiled C# or a deeper .NET/native implementation is often more appropriate.

The point is not only raw speed. It is also better structure, easier profiling, clearer memory management, stronger typing, testability, and more predictable behaviour.

Used By a Team or Client

Package and version it properly.

If other people depend on the tool, it should not exist as fragile embedded source code scattered across project files. A compiled .gha, distributed through a shared internal path, Yak package, private package source, or managed deployment process, is usually a better long-term pattern.

The Dependency Problem Is Real, But Solvable

One common argument for keeping scripts embedded in Grasshopper files is that dependencies are painful.

That concern is valid.

A Grasshopper file that depends on missing plug-ins, mismatched versions, untracked DLLs, or forgotten local paths can become difficult to open, share, or maintain.

However, this is a deployment problem, not necessarily an argument against compiled components.

For internal tools, several workable patterns exist.

Shared Internal Path

For small teams, plug-ins can be loaded from a shared network path or synced folder.

This keeps everyone on the same build and avoids manually sending .gha files around. It is not the most sophisticated solution, but it can be effective when the team is small and the deployment model is simple.

Yak / Rhino Package Manager

A more structured approach is to package components with Yak / Rhino Package Manager.

The Rhino Package Manager supports discovery, installation, and management of Rhino and Grasshopper plug-ins. It also provides package restore for Grasshopper, where missing plug-ins can be identified when opening a file and installed through the package system. McNeel’s documentation also notes support for file- or folder-based custom package repositories. (www.rhino3d.com)

This gives teams a cleaner way to handle:

• Versioning

• Installation

• Updates

• Package restore

• Internal distribution

• Reproducibility

Rhino’s newer scripting tooling also supports creating Grasshopper plug-ins from scripts and generating Yak packages, which makes the path from script to packaged tool more direct than it used to be. (www.rhino3d.com)

Separate Distribution From Entitlement

If access control or licensing matters, distribution and entitlement should be treated as separate concerns.

For example:

• Yak or a shared folder handles installation and updates.

• Authentication, licensing, feature flags, or user permissions are enforced inside the plug-in.

This is often cleaner than trying to control access only through file distribution. The package can be easy to install, while actual capability remains permissioned.

For larger organisations, this also helps with support. Teams can stay on known versions, updates can be rolled out gradually, and definitions become less fragile because they depend on maintained shared components rather than duplicated embedded scripts.

A Note on AOT

Ahead-of-time compilation is worth mentioning because it often appears in discussions about .NET startup performance.

However, it is probably not the main solution to the Grasshopper script-component problem.

Microsoft’s Native AOT documentation describes it as a deployment model with important limitations, including no dynamic loading via Assembly.LoadFile, no runtime code generation via System.Reflection.Emit, trimming constraints, and other compatibility considerations. (Microsoft Learn)

That matters because Grasshopper components are loaded into Rhino’s managed runtime, and the bottlenecks discussed here are usually tied to:

• Script preparation

• Cache invalidation

• Assembly loading

• Reference resolution

• Package/dependency loading

• Document startup behaviour

• Repeated script execution patterns

Those are not the same as simply eliminating JIT compilation from a standalone .NET executable.

AOT can absolutely be valuable in certain .NET deployment scenarios, especially where cold startup time, runtime footprint, or self-contained deployment matter. But for Grasshopper script components, it should not be assumed to solve the observed problem without careful testing.

The practical advice is simple:

Measure first. Do not assume AOT changes the bottleneck you are actually seeing.

Recommended Workflow

A good workflow is not to choose one language forever. It is to let the implementation mature as the use case matures.

Maturity Ladder

Stage 1: Explore on the Canvas

Use Grasshopper-native components, Python, or C# script components.

Optimise for speed of thought, not architecture.

Stage 2: Stabilise the Logic

Once the idea works, clean up the script.

At this stage:

• Remove repeated imports from hot paths

• Use List/Tree access correctly

• Avoid unnecessary type conversion

• Make input and output behaviour explicit

• Add basic comments

• Measure solve time separately from document load time

Stage 3: Extract Repeated Logic

If the same code appears in multiple definitions, move it out of the canvas.

This could mean:

• A shared script file

• A shared C# library

• A compiled Grasshopper component

• A Rhino/Grasshopper plug-in

• A package distributed internally

The goal is one canonical implementation.

Stage 4: Package for Teams

If other people need the tool, treat it as software.

That means:

• Versioning

• Release notes

• Compatibility expectations

• Dependency management

• Testing

• Documentation

• Deployment strategy

• Support workflow

At this stage, performance is only one part of the value. Reliability and maintainability often matter more.

Practical Checklist

Decision Flow

Same Logic as a Sankey: Each Yes Flows Toward the Decision

Cluster Weights as a Bar Chart: How Many Questions Each Axis Carries

Before deciding whether to keep logic in a script component or move it into a plug-in, ask:

• Is this logic used in more than one definition?

• Is the script component duplicated across files?

• Does the definition feel slow before solving geometry?

• Is build time being measured separately from solve time?

• Are imports or dependency setup repeated during execution?

• Are inputs configured as Item, List, or Tree appropriately?

• Does the script perform heavy geometry processing?

• Is the logic called many times inside a solution?

• Would a bug fix need to be applied in multiple files?

• Do other team members or clients depend on this tool?

• Would a versioned package make support easier?

• Would losing this embedded script create project risk?

If several answers are yes, the logic probably deserves to move out of the canvas.

Practical Takeaways

1. Measure build time separately from solve time.

2. Do not assume Python is always lighter.

3. Do not assume C# script components behave like compiled plug-ins.

4. Use List/Tree access intentionally.

5. Move repeated logic into a shared implementation.

6. Treat team tools as software.

7. Be cautious with AOT assumptions.

Why This Also Matters for Revit and Broader AECO Tooling

The same pattern appears in Revit development.

A Revit add-in, Dynamo graph, Grasshopper definition, Rhino plug-in, or internal automation script can begin as a small productivity tool. Over time, it becomes part of a real production workflow.

Once that happens, the engineering expectations change.

The tool now needs:

• Predictable deployment

• Version control

• Clear ownership

• Dependency management

• Error handling

• Logging

• Testing

• Documentation

• Compatibility strategy

• A support model

This is where computational design starts to overlap with professional software engineering.

In individual experimentation, raw speed of implementation matters most. In team and client workflows, reliability, reproducibility, and maintainability become just as important as milliseconds of execution time.

Conclusion

The practical answer is not “always use C#” or “always use Python”.

Use the canvas for what it is good at: fast thinking, visual experimentation, and project-specific glue.

But when logic becomes repeated, heavy, shared, or business-critical, it should move towards a proper software structure: shared libraries, compiled components, package-managed deployment, versioned releases, and maintainable architecture.

Grasshopper is an excellent environment for computational design, but large definitions can quietly become software systems. Once they do, they benefit from the same engineering discipline as any other production tool.

We will be publishing more on this soon, including deeper dives into Grasshopper scripting performance, plug-in architecture, deployment strategies, RhinoCommon optimisation patterns, and advanced Revit development topics on the Graph Technologies blog.