build: use latest nanobind in split mode

[robertodr]

Summary

New split mode in the upcoming nanobind 3 release series promises to reduce compile times by a lot and produce more efficient wheels. This PR is to keep track of its development and flag any issues early.

Changes

• Use latest nanobind and build the Python package in split mode.

Checklist

• Tests added or updated to cover the changes
• Documentation updated (docstrings, docs/, CONTRIBUTING.md) if needed
• CHANGELOG / release notes updated if applicable

AI/LLM disclosure

• I did not use LLM tooling, or used it only privately for ideation
• I used the following tool to help write this PR description:
• I used the following tool to generate or modify code:

Important

By opening this PR I confirm that I have read CONTRIBUTING.md and I agree to the terms of the Contributor License Agreement.

Warning

If you're contributing on behalf of your employer, contact cla@algorithmiq.fi to arrange a Corporate CLA.

[github-actions]

Docs preview: https://pr-243.monoprop-docs.pages.dev

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.70%. Comparing base (1b7533f) to head (43d61b9).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #243   +/-   ##
=======================================
  Coverage   97.70%   97.70%           
=======================================
  Files          14       14           
  Lines         742      742           
  Branches       98       98           
=======================================
  Hits          725      725           
  Misses         12       12           
  Partials        5        5           

Flag	Coverage Δ
cpp	97.70% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[robertodr]

🤖 AI text below 🤖

nanobind 3 benchmark results

Benchmarked using Python 3.12.14 and Release builds on the same host. Results are the median of five interleaved runs; lower is better.

Benchmark	nanobind 2	nanobind 3	With tuple_builder	Total improvement
Positional dispatch	72.1 ns	47.0 ns	47.2 ns	34.6%
Keyword dispatch	113.9 ns	84.6 ns	86.2 ns	24.4%
Bound size()	41.3 ns	48.4 ns	44.6 ns	-8.1%
Expectation-value functional	10.92 µs	10.45 µs	10.49 µs	4.0%
One-term conversion	9.05 µs	8.89 µs	8.82 µs	2.5%
1,024-term conversion	169.0 µs	126.4 µs	110.2 µs	34.8%

Conclusions

• nanobind 3 reduces positional dispatch latency by 34.8% and keyword dispatch latency by 25.8% without source changes.
• Replacing list-based tuple construction with nb::tuple_builder reduces 1,024-term conversion latency by a further 12.8%.
• The combined improvement for 1,024-term conversion is 34.8%.
• Functional and one-term conversion performance improve slightly.
• The size() difference is only a few nanoseconds and is considered inconclusive due to measurement noise.

[robertodr]

Ready to go when nanobind 3 is officially stable.

[robertodr]

PS: I don't think commit 43d61b9 adds much to our benchmarks, I'm ok with tossing it

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud