POC for hyperscan usage in UrlDispatcher

[asvetlov]

https://pypi.org/project/hyperscan/ could speed up url dispatcher if available.

Fallback to the current implementation is supported if hyperscan compilation fails or not available.

[codspeed-hq]

CodSpeed Performance Report

Merging #9907 will degrade performances by 26.77%

_{Comparing hyperscan (e1cbdf0) with master (3e81852)}

Summary

⚡ 3 improvements
❌ 3 regressions
✅ 37 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	master	hyperscan	Change
❌	test_resolve_dynamic_resource_url_with_many_dynamic_routes[pyloop]	3.7 ms	5.1 ms	-26.77%
⚡	test_resolve_dynamic_resource_url_with_many_dynamic_routes_with_common_prefix[pyloop]	259.5 ms	5 ms	×52
❌	test_resolve_dynamic_resource_url_with_many_static_routes[pyloop]	3.7 ms	5 ms	-25.51%
⚡	test_resolve_gitapi[pyloop]	316.6 ms	5.7 ms	×55
⚡	test_resolve_gitapi_subapps[pyloop]	320.1 ms	7.9 ms	×41
❌	test_resolve_static_root_route[pyloop]	1.1 ms	1.2 ms	-10.22%

[bdraco]

Haven't tested this yet but I expect it will break downstream Home Assistant since there is code there to register new routes as new integrations get loaded after startup. It's pretty clear the intent here was to not allow that after freeze but that's currently the downstream use case and hard to change it.

[asvetlov]

Good point.
We can rebuild hypedscan db in UrlDispatcher.register_resource() if the dispatcher was frozen.
I'm curious how Home Assistant works with route table on the fly.
If it adds new routes to started web server it should remove them at some point, isn't it?

Before moving forward, I'd like to add some benchmarks first.

[bdraco]

About to go to the airport, but will dig up the Home Assistant code this weekend. It predates me though so will take a bit to figure it out.

We don't have any benchmarks for the url dispatcher. I'll look at downstream use cases and come up with some after I get back from travel next week.

[asvetlov]

Have you safe flight!

[bdraco]

Once I figure out how the downstream code works for adding routes at run time. I'll see if I can make that into meaningful test cases here as well so we don't break anything. AFAICT for a cursory review, routes are never removed when integrations are unloaded downstream.

[bdraco]

Freezing and unfreezing on enter and exit will likely be too many rebuilds. ~297 routes get added at startup for Home Assistant. ~200 can be grouped together which would mean 200 rebuilds at startup

[bdraco]

Another method could be to keep adding to the fallback dict as new routes are added, clear the hyperscan db when a route is added after freeze, schedule a timer handle to rebuild the db a few (60... maybe less) seconds later if one is not already scheduled

[Dreamsorcerer]

~200 can be grouped together which would mean 200 rebuilds at startup

If they're grouped together, shouldn't that be 1 rebuild?

[bdraco]

Clarify: Very few can be grouped together. The result is 200 groups of various sizes, mostly 1

[bdraco]

Distribution of groupings looks something like 1, 9, 1, 7, 3, 3, 1, 1, 1, 1, 1 .....

However order is indeterminate as it relies on async task completion order

[bdraco]

Managed to finish the benchmarks before boarding the flight. They should run if you update with master.

Didn't have enough time to dig through downstream or write the tests yet though

[asvetlov]

Thank you!

[Dreamsorcerer]

Looks good to me. Seems we need a couple more tests for missing coverage though.

[bdraco]

Just realized Hyperscan likely doesn't work on armv7l so maybe we need benchmarks for with Hyperscan not available as well. Maybe not though since armv7l is now slowly disappearing from the landscape now that the RPi shortage is over

[asvetlov]

Just realized Hyperscan likely doesn't work on armv7l so maybe we need benchmarks for with Hyperscan not available as well. Maybe not though since armv7l is now slowly disappearing from the landscape now that the RPi shortage is over

Perhaps parametrized benchmarks will help to measure both hyperscan and domestic versions.
Also I'm planing to use parametrization for existing url_dispatcher tests (and maybe web_functional ones) for tests coverage and correctness checking.

[bdraco]

From the flame graph on cod speed it looks like test_resolve_gitapi_subapps is producing system routes (maybe 404s)

[asvetlov]

Good finding, thanks!
I'll modify benchmarks to check the resolved route to prevent this situation from becoming possible.

I guess an assertion will not hurt or significantly change timings.