Improve Java decoding benchmark
springmeyer opened this issue · 1 comments
Context
The Java decoding benchmark compares the speed of MLT decoding against two different libraries implementing https://github.com/mapbox/vector-tile-spec:
- https://github.com/ElectronicChartCentre/java-vector-tile
- https://github.com/sebasbaumh/mapbox-vector-tile-java
Problem
Both vector tile libraries are doing extra work that is not representative of what Maplibre needs.
Maplibre needs:
- "Lightweight layers": decoded layers that store offsets to features and only decode features when accessed by
layer.feature(idx)
. - "Lightweight features": decoded features containing just an
id
,extent
, andproperties
only - Then, as needed, Maplibre will call a function on those features called
feature.loadGeometry()
to on-demand, fetch a two-dimensionalArray<Array<Point>>
representation of geometries.
Rather what the Java vector tile libraries do are:
ElectronicChartCentre/java-vector-tile
- Creates a feature iterator when a layer is parsed. This is less work than fully decoding all features at Layer creation but does not allow skipping decoding of features that are not needed
- Decodes the geometry at Feature creation (rather than deferring geometry decoding to when needed)
- When decoding the geometry, a full JTS geometry is allocated
sebasbaumh/mapbox-vector-tile-java
Solution
We need to correct the Java benchmarks to compare against MVT decoding that is representative of what Maplibre expects.
MVT decoding that is representative of what Maplibre expects.
@mactrem here is a library in java that can be used to compare against: https://github.com/springmeyer/vector-tile-java. Let me know if you have any questions.