[FEA] Investigate performance of numba extension type registration in cuDF
- Dominant language
- C++
- Stars
- 9.8k
- Forks
- 1.1k
- Avg merge
- 3d 6m
- Merged PRs (30d)
- 278
Description
**Is your feature request related to a problem? Please describe.**
cuDF implements a number of different numba extension types to support various UDF APIs, and the GPU implementations of operations over those types are currently registered with numba at import time. Recent efforts reducing cuDF's import time have left these codepath as possibly the next lowest hanging fruit for optimization.
**Describe the solution you'd like**
A couple of ideas come to mind:
- Deferring registration until first API call (grouping it with current JIT overhead)
- Reducing the number of implementations that need to be registered by having fewer that are more general
- Improving actual registration speed upstream
**Describe alternatives you've considered**
- I have considered moving all extension types into an optional dependency.
**Additional context**
N/A
Contributor guide
Assessment
This issue has not been assessed yet.