Massive performance regression in map-matching for bikes

Noticed a massive performance regression for bike profile.

Using the up to date berlin PBF and a random manually generated GPX file with `config-example.yml` from current HEAD . Graphhopper Head needs around 16.7sec , while Graphhopper 11.0 around 2.7sec for me (11.0 using the config-example from HEAD)

java -Ddw.graphhopper.datareader.file=berlin-260907.osm.pbf -jar web/target/graphhopper-web-12.0-SNAPSHOT.jar server config-example.yml

curl --request POST --url 'http://localhost:8989/match/?profile=bike' --header 'Content-Type: application/gpx+xml' --data-binary @BerlinRoute.gpx

initial observation: snapsPerObservation increased a lot from 11.0 → HEAD.

BerlinRoute.gpx (52.5 KB)

Tricky to say what could cause this. Can you do a rough bisect to pin it down to a few commits only?

It is commit a828d582abf28fccb415774cd9e08b9fb08ddb1b ROTFL

Commit a828d582abf28fccb415774cd9e08b9fb08ddb1b (HEAD → bisect11)
Author: Michael Zilske ...@graphhopper.com
Date: Thu Mar 12 19:49:58 2026 +0100

let's say 2 sigma

Reverting this commit fixes the regression for me

Thanks, will investigate!