Repository navigation
Perfomance improvement for flex access/egress searches - #3661
Conversation
1e95755 to
15bf538
Compare
|
After having identified the linestring computation as a major bottleneck during the the dev meeting I added a commit which only generates them when they are actually needed, not for the thousands of possible paths that will never be presented to the user. This leads to even more significant performance gains. Typical stats are these: |
7fbcf17 to
92d0f8c
Compare
|
I have also implemented what we talked about in the meeting: limiting the distance that a transfer can take when getting in or out of a flex vehicle. If I configure it to be 300m then I typically get the following times: |
34ae3e5 to
5fbf2da
Compare
| *Config parameters* | ||
|
|
||
| - `maxTransferMeters`: how far should you a passenger be able to walk after getting out of a flex | ||
| vehicle and transferring to another one. |
There was a problem hiding this comment.
"another one" - Another FLEX or Transit vehicle?
| - `maxTransferMeters`: how far should you a passenger be able to walk after getting out of a flex | ||
| vehicle and transferring to another one. | ||
| This was mainly introduced to improve performance - a lower value means that | ||
| the routing is faster. |
There was a problem hiding this comment.
Is there an upper limit? This is equivalent to the maxTransferDurationSeconds, so we should use the same unit.
… the linestring to the latest possible time
…edTrip.java Co-authored-by: Thomas Gran <t2gran@gmail.com>
9f755cd to
85fbfb5
Compare
849d6df to
da5bae8
Compare
eb188e7 to
3ab9c93
Compare
|
I also took the liberty to also bring the configuration for the vector tiles in line with what @t2gran has requested for the flex one. |
The long term goal here is to modularize the code a bit, and hopefully this will make it a bit simpler to infer a dependency-injection framework. |
Summary
We noticed a severe performance problem for flex access/egress searches which would typically be 5-10 times slower than flex direct searches. I also saw that for flex access/egress searches a large number (25000 in my simple case with a hand full of flex routes) of accesses are computed. For this reason I added their number to the debug output.
After a bit of investigation I noticed some performance improvements in #3499 which I extracted into this separate PR. The core of this solution is to stop every flex path from being traversed twice.
Results
Before:
After:
The improvement is very noticeable but in my view it went only from terrible to bad.
To achieve an even better performance I think we need to dramatically lower the number of accesses being computed.
For example, if I run the same request without flex, the timing looks like this:
Unit tests
I would love to write a unit test for flex but I think I need some guidance on how to do it.
Code style
Yes.
Documentation
I've commented the code.
Changelog
Yes