Same LEPCC point clouds. 14.4× faster to encode in bulk.
LEPCC is the compression inside Esri's I3S scene layers, the point clouds ArcGIS streams to every 3D viewer. TurboLEPCC writes and reads the same bytes as Esri's library, faster, in memory-safe code, and every ArcGIS client reads its output unchanged.
Swaps in for Esri's liblepcc. Native on servers, and in the browser too.
Against Esri's C++ reference, measured in the same session on the same machine. Benchmarks dated 2026-06-10.
The 60-second version
ArcGIS streams its 3D point clouds packed with LEPCC.
LEPCC
Esri's point-cloud compression, inside the I3S scene layers that ArcGIS Online, ArcGIS Pro and the ArcGIS web viewers stream: positions, intensity, color and classes.
Esri's library
liblepcc, the open-source C++ reference. Every LEPCC pipeline links it today, so it is the bar any replacement has to clear, on the same bytes.
Publish once, stream always
Every scene layer is encoded when it is published, then decoded by every viewer that opens it. Publishing time is compute; decode time is what users wait for.
A memory-safe drop-in
TurboLEPCC writes the same bytes as Esri's encoder and reads everything Esri's library writes, so it swaps in without changing a single viewer.
Watch it
Race it yourself, in this tab.
A real 1.06M-point lidar scan decoded in your browser: TurboLEPCC against Esri's own decoder on the same bytes, rendered over satellite imagery, with BVC and LAZ/COPC lanes to compare. Drag either map; the cameras are linked.
What it means for the bill
Publish faster. Serve faster. Change nothing else.
The batch figures, translated.
Illustrative, from the measured batch figures. A pilot measures yours.
Every subsystem, both machines
Faster than Esri's library on 21 of 24 tests.
LEPCC has three compressed subsystems behind one API: point geometry, lidar intensity and per-point color. Each was encoded and decoded on two workloads, on Windows and on a Mac, against Esri's C++ reference in the same session. One core each side. No cherry-picks: every result is below.
Source: turbo-lepcc-rs criterion benchmarks vs the Esri C++ reference (liblepcc, Apache-2.0), median time across a small real LiDAR scan plus mid-size and large synthetic point batches. Whiskers show the spread across those workloads; a single bar means the workloads tied within 5%.
Not won: per-point color decode, random 10K, Windows (0.93×, tied); per-point color decode, low-variety 10K, Windows (0.96×, tied); per-point color encode, low-variety 10K, Mac (0.81×). The Mac color-encode gap comes from Esri's macOS build using a faster hash for its color table; the same code runs 13.4× faster on Windows.
At scale
From one scan to ten million points.
Whole point clouds, encoded and decoded end to end on Windows. The turbo setting writes smaller files that Esri's library still reads; the default writes Esri's exact bytes.
| Point cloud | Encode vs Esri | Decode vs Esri | Turbo setting size |
|---|---|---|---|
| Real lidar (Autzen) | 1.75× | 1.14× | −2.9% |
| Grid, 1M points | 0.92× | 1.31× | −25.8% |
| Random, 1M points | 1.95× | 1.17× | −1.8% |
| Grid, 10M points | 1.05× | 1.49× | −35.8% |
| Random, 10M points | 1.73× | 1.17× | −1.9% |
Single point clouds, one at a time. In bulk (1,000 clouds of 10,000 points) TurboLEPCC's batch API encodes at 212 million points a second against Esri's 15, and decodes at 223 against 94, because Esri's library only works one cloud at a time.
The memory-safe field
The only memory-safe LEPCC library faster than Esri's.
There is one other memory-safe LEPCC implementation in public. It decodes only, and TurboLEPCC decodes 34–61× faster. Log scale below.
Decode time for a small real LiDAR point cloud (a public Esri reference scan), macOS aarch64 NEON. Log scale because the only other memory-safe port sits roughly a generation behind. TurboLEPCC is the only memory-safe port that beats the Esri C++ reference.
What's in the box
Every LEPCC subsystem, one API.
XYZ
Point geometry
Quantized 3D coordinates: the bulk of a lidar or photogrammetry point cloud.
1.57×–2.39× on Windows, 1.18×–1.89× on a Mac
Intensity
Lidar return intensity
Per-point 16-bit signal strength, used for surface classification.
1.25×–2.41× on Windows, 2.38×–4.10× on a Mac
RGB
Per-point color
Per-point 8-bit color triplets with cluster-aware compression.
0.93×–13.4× on Windows, 0.81×–1.89× on a Mac
FlagBytes
Classification flags
Per-point classification and flag bytes: terrain, vegetation, building and more.
Byte-exact with Esri's library
Same bytes
Byte-exact with Esri, checked four ways.
Round-tripping its own files is not enough. Every test case must satisfy all four checks against Esri's C++ reference.
Check A
Reads Esri's files exactly as Esri does
our_decode(esri_blob) == esri_decode(esri_blob)
Every Esri-encoded payload decodes to the same bytes through TurboLEPCC as through Esri's own C++.
Check B
Writes the bytes Esri writes
our_encode(data) == esri_encode(data)
Encoded output is byte-identical to Esri's. Downstream consumers cannot detect the swap.
Check C
Lossless forwards
our_decode(our_encode(data)) == data
Every payload TurboLEPCC encodes comes back exactly.
Check D
Lossless backwards
our_encode(our_decode(blob)) == blob
Re-encoding an Esri file gives back the original bytes. No silent transcoding.
Drops into the pipeline
A library swap. Not a migration.
- - Byte-exact with Esri's liblepcc on encode and decode: no consumer changes, no transcoding, no risk of silent drift.
- - Memory-safe, with no unsafe code, and deployable in the browser (WebAssembly SIMD) for I3S point-cloud rendering with no C dependency.
- - Faster than Esri's library on 21 of 24 tests on one core (10 of 12 on Windows with 2 tied, 11 of 12 on a Mac), and 14.4× in bulk.
- - 34–61× faster than the only other memory-safe LEPCC port, which decodes only.
- - Every subsystem behind one native API: point geometry, lidar intensity, per-point color, classification flags.
- - SIMD backends: AVX2, NEON, WASM SIMD128, SVE2 (nightly), and a scalar fallback.
How this was measured
- Machines: Windows, MSVC, AVX2 (re-benched 2026-06-10) and Apple M-series, NEON, each against Esri liblepcc (C++), measured in the same session. The two machines are never divided into one ratio.
- Per-subsystem tests: one core each side, criterion medians, on two workloads per subsystem (the Autzen lidar sample and synthetic 10K or 64K sets; random and low-variety color). Ratio is Esri's time divided by ours.
- At scale and in bulk: whole point clouds from 110,000 to 10 million points, and 1,000 clouds of 10,000 points through the batch API on every core, on Windows (2026-06-10).
- The live race decodes in your browser against Esri's published WebAssembly build, so its numbers are yours, not ours.
Bring five of your scene layers.
A pilot runs both libraries on your own point clouds, on your own machine: same data in, same bytes out. You keep the numbers.
TurboLEPCC is licensed through the Bitruvius Developer Hub and ships as compiled binaries.
Esri, ArcGIS, I3S, and LERC are trademarks of Environmental Systems Research Institute, Inc., used here solely to identify the products and formats being compared. No affiliation, sponsorship, or endorsement is implied. LEPCC is published by Esri under the Apache 2.0 license, and the live demo runs Esri's unmodified reference decoder under that license; TurboLEPCC is an independent implementation of the LEPCC format. Benchmark data includes the Autzen Stadium lidar scan, the openly distributed dataset popularized by the PDAL project. Performance comparisons reflect our own measurements under the stated methodology; results vary by workload and hardware. Full third-party notices: Attributions.