Revert allow multiple states during transfer edge traversals #6357
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev-2.x #6357 +/- ##
=============================================
- Coverage 69.85% 69.84% -0.02%
+ Complexity 17927 17919 -8
=============================================
Files 2035 2035
Lines 76509 76506 -3
Branches 7825 7823 -2
=============================================
- Hits 53446 53434 -12
- Misses 20324 20330 +6
- Partials 2739 2742 +3 ☔ View full report in Codecov by Sentry. |
|
I will also try this out in our test environment. It currently takes about 2 minutes for walk and 5 minutes for bike for a response with a new configuration on our test environment with about 6M walk and 15M bike transfers. In particular, I will check if both walk and bike route planning still works correctly. |
|
I have deployed this change in Aubin (GB wide data) test server. The response time of a new preference has been improved to about half a minute for walk, and 75 seconds for bike, whereas before it was about 2 minutes for walk and 5 minutes for bike. |
|
I can confirm that this PR makes start up and transfer cache computation a lot faster. In order to have some hard numbers I also added some data to the speed test: #6362 |
| var states = e.traverse(s); | ||
| if (State.isEmpty(states)) { | ||
| s = null; | ||
| } else { | ||
| transferStates.add(states[0]); | ||
| s = states[0]; | ||
| } |
There was a problem hiding this comment.
We can revert this for the performance benefit. It may be useful to add a check here to avoid problems related to A* searches returning multiple states similar to EdgeTraverser.
|
For reference, flame graph showing the impact of #6238 on RaptorRequestTransferCache
|
Summary
This PR reverts #6238 which seems to cause performance issues in our production environment.
This PR is not intended to be merged, but only to be used for further investigating the issue.
Issue
No
Unit tests
No
Documentation
No