Skip to content

PERF: speed up dtype.name - #33059

Open
lazerg wants to merge 2 commits into
numpy:mainfrom
lazerg:perf-dtype-name-get
Open

lazerg wants to merge 2 commits into
numpy:mainfrom
lazerg:perf-dtype-name-get

Conversation

@lazerg

@lazerg lazerg commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

PR summary

dtype.name goes through _name_get in _dtype.py. Most of its time went to _name_includes_bit_suffix, which called np.issubdtype(dtype, np.flexible). It now calls issubclass(dtype.type, np.flexible), which gives the same answer because dtype.type is already a scalar type at that point. The C getter also re-imported numpy._core._dtype and looked up _name_get by name on every access. It now caches the function in the module's runtime imports, the same way _commastring and _usefields are cached.

Timings with the reproducer from the issue (macOS arm64, Python 3.14):

dtype main this PR
float32 1.29 µs 0.50 µs
int64 1.24 µs 0.60 µs
bool 0.75 µs 0.50 µs
<U5 1.30 µs 0.56 µs
datetime64[ns] 1.41 µs 0.67 µs
StringDType() 1.14 µs 0.44 µs

The returned names don't change. Almost all of the remaining time is spent in the Python function itself, so getting down to tens of nanoseconds would mean moving _name_get to C.

Closes #33051

AI Disclosure

I used Claude Code here. It profiled dtype.name and drafted the change, so the edits to descriptor.c, module_state_fields.h and _dtype.py and the text of this description are AI generated. I built numpy from source and checked the timings and the test suite myself before opening the PR.

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.

PERF: dtype.name access overhead

1 participant