ctuu opened a new issue, #487:
URL: https://github.com/apache/tvm-ffi/issues/487

   ## 1. Problem Statement
   
   The `tvm-ffi` package currently uses a Python-based configuration tool 
(`tvm_ffi.config`) to provide metadata (headers, library paths) to external 
build systems. However, importing this tool triggers a full package 
initialization.
   
   When **PyTorch+CUDA** is present in the environment, the overhead is 
catastrophic. The Python interpreter must load massive binary frameworks and 
initialize the GPU driver/context just to retrieve a simple string path.
   
   ---
   
   ## 2. The Two Scenarios
   
   ### Scenario A: CMake `find_package()`
   
   When using `find_package(tvm_ffi CONFIG REQUIRED)`, CMake executes the 
Python interpreter multiple times to resolve variables like `includedir` and 
`libfiles`.
   
   
https://github.com/apache/tvm-ffi/blob/b1abaeac7103606a458d2bb91438652030d5ae88/cmake/tvm_ffi-config.cmake#L25-L41
   
   * **The Cost:** On a system with PyTorch+CUDA, this adds **7–10 seconds** to 
every configuration run.
   * **The Risk:** It creates a hard dependency on Python environment during 
the C++ build phase, violating principles of hermetic builds.
   
   ### Scenario B: Python CLI & Other Build Systems
   
   Even when querying paths directly via the CLI (used by Meson, Bazel, or 
manual scripts), the latency is unacceptably high.
   
   ```bash
   # In an environment with PyTorch + CUDA
   $ time python -m tvm_ffi.config --includedir
   /path/to/include
   
   real    0m2.3s 
   
   ```
   
   * **The Root Cause:** `tvm_ffi.config` is tightly coupled to `__init__.py`. 
Importing it triggers a "Heavy Initialization Sequence":
   1. **Framework Loading:** Loads GBs of PyTorch/CUDA shared objects.
   2. **Hardware Handshake:** GPU driver context initialization.
   3. **Symbol Resolution:** Thousands of symbols resolved across heavy 
binaries.
   
   
   
   ---
   
   ## 3. Recommended Solution (Scenario A)
   
   I recommend moving to a **Native CMake Target Export** model. This is the 
industry-standard "clean way" to handle C++ library discovery.
   
   * **Implementation:** Use `install(EXPORT)` to generate a static `.cmake` 
file during the installation of `tvm-ffi`.
   * **Why it works:** It shifts the work from **runtime discovery** (calling 
Python) to **install-time generation**.
   * **Result:** `find_package()` becomes a near-instant ($<0.01\text{s}$) file 
read. It works offline and without Python installed.
   
   ---
   
   ## 4. Discussion (Scenario B)
   
   For Scenario B, there is no single "best practice" yet, and I am throwing 
this open for discussion. Since we cannot use CMake exports for a Python CLI, 
how should we provide a "fast-path" for metadata?
   
   **Potential directions for discussion:**
   
   * **Bypassing `__init__.py`:** Should we refactor the module structure to 
allow `config.py` to run without triggering the root package imports?
   * **Declarative Metadata:** Should we store these paths in a `metadata.json` 
or `PKG-INFO` during the build process so they can be read as raw text?
   * **importlib.metadata:** Should we leverage the Python distribution's 
metadata entry points?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to