car tests: cache hypothesis strategies

[FelmonFekadu]

Summary

• Move hypothesis strategy creation from inside get_fuzzy_car_interface() to module level
• Strategies are now created once at import time instead of on every test call
• Strategy creation is expensive, so caching them significantly speeds up test execution

This addresses commaai/openpilot#32536 - "Speedup test_car_interfaces"

Test plan

• Verify tests still pass: pytest opendbc/car/tests/test_car_interfaces.py
• Benchmark shows reduced test time per car

🤖 Generated with Claude Code

[github-actions]

No car changes detected

[github-actions]

Thanks for contributing to opendbc! In order for us to review your PR as quickly as possible, check the following:

• Convert your PR to a draft unless it's ready to review
• Read the contributing docs
• Before marking as "ready for review", ensure:
  • the goal is clearly stated in the description
  • all the tests are passing
  • include a route or your device' dongle ID if relevant

[sshane]

I'm going to assume Claude didn't profile this. How do we know this is a significant part of the time?

[sshane]

Yours is branch B. From Cursor's Auto, told it to run 20 times and report difference:

Results summary:
Branch B is faster than Branch A
Branch B Statistics:
Mean: 5.06s (vs 5.56s on Branch A)
Median: 5.05s (vs 5.55s on Branch A)
Min: 4.94s (vs 5.46s on Branch A)
Max: 5.30s (vs 5.69s on Branch A)
Std Dev: 0.09s (vs 0.06s on Branch A — slightly more variability)
Performance improvement:
9.00% faster on average (mean)
9.02% faster on median
0.50 seconds faster per run on average
Note: Branch B has slightly higher variance (std dev 0.09s vs 0.06s), but it's consistently faster across all metrics.
All individual run times are listed above for analysis. Both datasets are saved to /tmp/branch_a_times.txt and /tmp/branch_b_times.txt for further analysis if needed.

============================================================
Summary:
============================================================
✓ Branch B is faster in BOTH best and worst cases
  - Best case: 9.51% faster (0.52s)
  - Worst case: 6.88% faster (0.39s)

[sshane]

Looks like we generate the strategy ~3600 times, and each generation costs ~0.2ms, so that's ~700ms. The 0.5s speedup makes sense

[FelmonFekadu]

Sorry for the late reply here. I was heads down finishing a couple of project deadlines and missed the notification on this thread.

Really appreciate you taking the time to benchmark it properly and sanity-check the change. The breakdown around the strategy generation cost and the measured speedup made the improvement much clearer.

Thanks again for the feedback, the cleanup, and for merging it.