Skip to content

performance gains - #588

Merged
rafapereirabr merged 5 commits into
masterfrom
dev
Oct 9, 2026
Merged

rafapereirabr merged 5 commits into
masterfrom
dev

Conversation

@rafapereirabr

Copy link
Copy Markdown
Contributor

No description provided.

Rafa Pereira and others added 4 commits October 8, 2026 10:23
R5's McRAPTOR target pruning only runs when request.maxFare < 0, but r5r passed
Integer.MAX_VALUE without a fare structure, so every Monte Carlo draw searched the whole
network. TripPlanner now:
- turns the pruning on during route() when there are no fares, and resets R5's best time at
  the target at the start of each draw (it is kept across draws upstream, which would prune
  valid trips of later draws); a guard throws if R5 stops calling the hook once per draw;
- drops states later than the draw's departure + max_trip_duration (as FareDominatingList
  already does), and with shortest_path also states slower than the fastest trip found so far.

Results are unchanged (15 + 9 scenarios on poa/spo); only with suboptimal_minutes > 0 can the
option numbers of exactly tied itineraries swap. About 1.5x faster at max_trip_duration = 60
and about 4x with the defaults (100 pairs, 2 cores). Routing with fares is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
R5TravelTimeComputer, r5r's copy of R5's TravelTimeComputer, ran a second street search on
foot after every car or bicycle search, also without transit. Upstream R5 v7.5 runs it only
with transit (to reach stops in pedestrian-only areas). Car-only and bicycle-only routing in
travel_time_matrix(), expanded/arrival_travel_time_matrix(), accessibility() and
pareto_frontier() is 2.5 to 4 times faster. Bicycle results are unchanged; some car-only
trips no longer end with a walk not limited by max_walk_time and get 1 to 8 minutes longer
(3% of pairs in poa), now consistent with isochrone().

Also build the travel_time_pNN column names once per origin instead of per destination.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Performance gains for detailed_itineraries() and car/bicycle travel time matrices
(performance_gain protocol).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@rafapereirabr

Copy link
Copy Markdown
Contributor Author

r5r benchmark: CRAN 2.4.0 vs dev 2.4.0.9001

  • dev: 781f4475 plus the uncommitted start_r5r_java() fix (java.parameters). The fix has no effect here because the JVM is started by the harness.
  • Both versions: R5 7.5.1, JDK 21, the JVM started by the harness with -Xms64G -Xmx64G -XX:ActiveProcessorCount=8, n_threads = 8.
  • Machine: shared Windows Server 2022, 16 logical CPUs, 256 GB RAM. Run 2026-10-08 19:36 to 2026-10-09 02:53.
  • Inputs: 500 origins × 500 destinations (all-to-all), seed 42. For detailed_itineraries(): 50 × 50 all-to-all = 2,500 itineraries.
    • poa: drawn from the hexgrid.
    • spo: 323 hexes resampled with ≤ 150 m jitter.
  • Settings: max_trip_duration = 60, departure/arrival 13-05-2019 14:00, other arguments at their defaults.
  • Order: 3 reps, CRAN/dev order alternated per rep; medians reported.
  • Not run: transit detailed_itineraries() on spo. Its GTFS is frequency-based, which both versions reject.

Transit (WALK + TRANSIT)

function city time CRAN (s) time dev (s) time gain memory CRAN (MB) memory dev (MB) memory gain
detailed_itineraries (shortest_path TRUE) poa 286.8 144.3 2.0× (-50%) 1,369,620 563,287 -59%
detailed_itineraries (shortest_path FALSE, suboptimal 10) poa 5420.4 2336.1 2.3× (-57%) 9,467,190 4,907,369 -48%
travel_time_matrix poa 1.8 1.6 1.1× (-6%) 3,660 2,703 -26%
travel_time_matrix spo 2.8 3.8 0.8× (+32%) 5,781 5,631 -3%
expanded_travel_time_matrix poa 6.9 6.2 1.1× (-10%) 13,172 13,361 +1%
expanded_travel_time_matrix spo 20.8 20.5 1.0× (-1%) 26,416 26,343 -0%
arrival_travel_time_matrix poa 15.3 13.1 1.2× (-15%) 50,414 51,583 +2%
arrival_travel_time_matrix spo 30.5 31.0 1.0× (+2%) 99,654 100,089 +0%
accessibility poa 1.3 1.0 1.3× (-20%) 1,661 1,664 +0%
accessibility spo 1.0 1.1 1.0× (+4%) 3,465 3,465 +0%
pareto_frontier poa 38.1 29.4 1.3× (-23%) 230,772 230,406 -0%
pareto_frontier spo 2.6 2.9 0.9× (+10%) 7,559 7,560 +0%
isochrone poa 31.8 28.3 1.1× (-11%) 11,252 15,736 +40%
isochrone spo 22.5 21.9 1.0× (-3%) 4,372 5,382 +23%

Car

function city time CRAN (s) time dev (s) time gain memory CRAN (MB) memory dev (MB) memory gain
detailed_itineraries (shortest_path TRUE) poa 3.4 1.7 2.0× (-49%) 1,298 1,300 +0%
detailed_itineraries (shortest_path TRUE) spo 2.8 2.8 1.0× (-2%) 848 849 +0%
detailed_itineraries (shortest_path FALSE, suboptimal 10) poa 2.8 1.8 1.5× (-35%) 1,297 1,299 +0%
detailed_itineraries (shortest_path FALSE, suboptimal 10) spo 2.4 2.2 1.1× (-9%) 843 843 +0%
travel_time_matrix poa 18.7 2.7 7.0× (-86%) 21,948 9,265 -58%
travel_time_matrix spo 3.1 0.7 4.3× (-77%) 7,058 2,456 -65%
expanded_travel_time_matrix poa 21.4 5.9 3.6× (-72%) 23,586 11,585 -51%
expanded_travel_time_matrix spo 17.5 13.5 1.3× (-23%) 14,997 10,311 -31%
arrival_travel_time_matrix poa 16.5 2.8 5.8× (-83%) 22,313 10,564 -53%
arrival_travel_time_matrix spo 2.5 1.1 2.3× (-56%) 7,840 3,426 -56%
accessibility poa 16.7 2.8 5.9× (-83%) 21,265 9,052 -57%
accessibility spo 2.1 0.5 4.4× (-77%) 6,807 2,400 -65%
pareto_frontier poa 32.9 5.6 5.9× (-83%) 43,486 18,504 -57%
pareto_frontier spo 5.0 1.2 4.3× (-77%) 13,725 4,894 -64%
isochrone poa 37.7 33.7 1.1× (-11%) 14,283 14,530 +2%
isochrone spo 25.1 18.3 1.4× (-27%) 3,944 3,945 +0%

Median of 3 reps. Time gain = CRAN/dev speed-up (% change in time). Memory = memory allocated during the call by Java (all threads) + R; peak Java heap and the parts are in the CSV.
Max coefficient of variation of time across reps: CRAN 35%, dev 28%.

Row-count differences > 1%:

  • transit / arrival_travel_time_matrix / poa: nrow CRAN 118316, dev 155019
  • transit / arrival_travel_time_matrix / spo: nrow CRAN 181696, dev 210753

Resuls are identical on all cases, except on a few cases where the dev versions fixes bugs, like in arrival_travel_time_matrix

start_r5r_java() called rJava::.jinit(parameters = c(log_path, ...)),
which replaces .jinit()'s default getOption("java.parameters"). Since
v2.2.0 a user's -Xmx (and any other JVM option) was silently dropped and
Java ran with its default heap. The user's options are now prepended to
r5r's own -D flags. Verified in a fresh session: -Xmx60G gives a 60 GB
heap (29.5 GB before, the JVM default on a 256 GB machine).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@rafapereirabr
rafapereirabr merged commit edcfd16 into master Oct 9, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant