Skip to content

Faster startup: ezdxf and vtk imported on use - #2097

Open
kimstik wants to merge 3 commits into
CadQuery:masterfrom
kimstik:dxf_vtk
Open

kimstik wants to merge 3 commits into
CadQuery:masterfrom
kimstik:dxf_vtk

Conversation

@kimstik

@kimstik kimstik commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

import cadquery loaded ezdxf and vtk although most sessions never touch a DXF or a render window. They are now imported by the functions that use them, and a test in a fresh interpreter keeps them out.

Here the import drops from 1.50 to 1.10 seconds - 0.35 for ezdxf with fontTools, 0.15 for vtk - and loads 417 modules instead of 693.

Annotations that name vtk types are forward references now; typing.get_type_hints() on those five functions resolves them once vtk is imported.

@kimstik

kimstik commented Sep 15, 2026 •

Copy link
Copy Markdown
Contributor Author

The rest is OCP: registering 321 packages on import, which costs about a second.
Cadquery needs half of them.
Lazy registration in the generator would recover about 0.5 seconds.
Nanobind would go further I guess.

upd:
lazy registration shows 0.16 sec instead of 0.79 on import OCP
requires basic OCP patching CadQuery/OCP#226

@kimstik
kimstik marked this pull request as ready for review September 15, 2026 16:36
@codecov

codecov Bot commented Sep 15, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 62.85714% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.68%. Comparing base (cb26a27) to head (1c4d0e9).
⚠️ Report is 4 commits behind head on master.

Files with missing lines Patch % Lines
cadquery/occ_impl/exporters/__init__.py 53.33% 4 Missing and 3 partials ⚠️
cadquery/occ_impl/assembly.py 71.42% 1 Missing and 1 partial ⚠️
cadquery/occ_impl/importers/__init__.py 66.66% 1 Missing and 1 partial ⚠️
cadquery/occ_impl/shapes.py 33.33% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2097      +/-   ##
==========================================
- Coverage   95.76%   95.68%   -0.08%     
==========================================
  Files          30       30              
  Lines        9584     9621      +37     
  Branches     1437     1448      +11     
==========================================
+ Hits         9178     9206      +28     
- Misses        250      254       +4     
- Partials      156      161       +5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@adam-urbanczyk

Copy link
Copy Markdown
Member

Thanks, but with the exception of shapes, I'd like those files not to be touched. E.g. it does not make sense to me to make the dxf module lazy when its main dep is ezdxf. I'd rather have the top level CQ modules import them inside of the relevant methods (Sketch.export, Workplane.export, Assembly.export, ...).

@kimstik

kimstik commented Sep 20, 2026 •

Copy link
Copy Markdown
Contributor Author

My reasoning was to put each import next to its only use, so that the change stays small and no caller of dxf.py can bring ezdxf back by accident - two files, a dozen lines. Your split reads better in the package, though: the core does not import the I/O modules until it exports, and dxf.py stays a plain module about ezdxf. Agreed.

To keep vtk out of import cadquery as well, toVTK() in occ_impl/assembly.py needs its import moved inside - two lines.

OK to touch that one, or ezdxf only for now @adam-urbanczyk ?

@adam-urbanczyk

Copy link
Copy Markdown
Member

Yeah, not problem with changing toVTK

As suggested in review, the I/O modules keep plain imports and the
functions that export or import load them. STEPExportModeLiterals moves
to types, so that Assembly.export needs no exporter import.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants