Ruby API performance advice for large parametric kitchen plugin (SketchUp 2017/2018+ target)

Developers Ruby API
,
1

Hi SketchUp developers,
I’m working on a Ruby parametric kitchen plugin and I’d like advice on improving execution time when generating many geometries.

Context

  • The plugin generates full kitchen compositions: tall cabinet blocks, base cabinets, corner modules, wall units, backsplash/tile surfaces, etc.

  • Large projects can contain many positions/modules, each creating multiple groups/faces.

  • We previously faced stability issues in some complex section merges (especially in tall cabinet blocks) when using boolean operations (union, outer_shell) on difficult/non-manifold geometry.

  • For safety, we now use a fallback path in risky cases (nested grouping + flatten/explode style merge), which improves stability but can increase generation time.

Version scope

  • We currently benchmark mostly on SketchUp Pro 2022.

  • However, the plugin will be sold for SketchUp 2017/2018 and newer.

  • So we are looking for performance strategies that are robust across versions, not only 2022-specific optimizations.

Current pipeline (simplified)

  1. Build geometry per module/section.

  2. Merge wall-like shells (sometimes boolean chain on copies for safety).

  3. Apply materials and UV mapping.

  4. Run cleanup passes (purge_unused, seam/edge cleanup, optional smoothing/hiding).

What we observe

Depending on layout complexity and risky cases, total generation can range from a few seconds to over 10 seconds.

Questions

  1. For large procedural models, what Ruby API strategies usually provide the biggest speed gains?

  2. What is the best way to reduce expensive boolean chains while preserving visual continuity?

  3. Are there recommended patterns to reduce overhead from many groups/components during generation?

  4. In practice, what should be prioritized first:

    • fewer boolean operations,

    • more component instancing,

    • delayed material/UV application,

    • fewer cleanup passes,

    • or different entity organization?

  5. Are there known performance pitfalls specific to supporting SketchUp 2017/2018+?

Notes

  • We already wrap generation in model.start_operation(..., true).

  • Stability in risky/non-manifold cases is mandatory.

  • If helpful, I can share a reduced test case or pseudo-code of the generation flow.

Thanks in advance for any guidance.