Perf

[dabreegster]

Just a backlog of things to improve performance.

• Clone the bicycle_direct router upon loading; don't serialize it
• gzip the .bin files
• Try web workers for all interactions
• For expensive OD calculations, try web workers with many threads
• Ship less GeoJSON to the frontend (consolidating datasets, matching IDs to new state, etc)
• Start the WASM, savefile, etc loading concurrently with the map setup

[dabreegster]

I've been looking into the overhead of frequent calls like renderDynamicRoads. In EDB, the Rust code takes 50ms total (including producing the JSON string), but from the frontend, it takes 250ms total. The overhead comes from copying a big string (about 12MB), JSON.parsing it, and then transferring with Comlink.

I tried serde_wasm_bindgen::to_value, which is supposedly faster than JSON, but it's about the same or a little slower.

[dabreegster]

So... Comlink does structured cloning. I just tried moving the JSON.parse over to the other side, and seemingly saved about 50ms total from that 250ms.

[dabreegster]

Aaaand by avoiding the structured clone of the string and just transferring the byte array directly, it's down to about 150ms now. From 250 to 150 originally.

I'll test carefully and roll this out to all the calls. Wow. Wish I had understood this ages ago. Comlink docs could use some work.

[dabreegster]

renderStaticRoads is another big call, only done once at startup. About 1200ms now... down to 600-700ms with this trick. OK, I'll take it :)

[mvl22]

The overhead comes from copying a big string (about 12MB)

That sounds quite a lot for a main roads network - does that have lat/lon values going into excessive digits perhaps? 6dp is always enough as that gives you 0.1m resolution.

600-700ms

That sounds perfectly acceptable even for a blocking call. Great work.

[dabreegster]

That sounds quite a lot for a main roads network - does that have lat/lon values going into excessive digits perhaps? 6dp is always enough as that gives you 0.1m resolution.

The precision is OK, but there are some really verbose property names and values:

npw/web/src/types.ts

Line 268 in 20a5340

export interface StaticRoad {

There's some easy things I can do to shrink this further. But now the JSON parsing only happens once, so it shouldn't be as big a problem.

More generally when I've been demoing the tool lately, some things feel frustratingly sluggish, so I've been trying to make improvements. I have some things I want to look into next, like why the "review route sections" screen is slow to set up the table and if self-hosting pmtiles would lead to a snappier basemap. (Zooming in quickly is slow, even on fast internet -- it could be the maplibre rendering though?)

[mvl22]

if self-hosting pmtiles would lead to a snappier basemap. (Zooming in quickly is slow, even on fast internet -- it could be the maplibre rendering though?)

The NPT site is obviously doing self-hosting, so you could benchmark your expectations against that?