CloudCutter E57 Benchmark 01: First Large-File Baseline

This is the first entry in the CloudCutter performance-test series. Its purpose is not to present a final performance claim or declare a benchmark victory. It establishes a reproducible baseline, confirms what already works, and identifies the most important architectural limitation to address next.

The result is encouraging: CloudCutter remained usable while the source was still being refined, completed the full read with moderate memory consumption, and created 20 valid RGB E57 files from one export command. The same test also exposed a large and measurable export inefficiency: the current safe split path rereads the source point stream once for every output.

That finding now defines the next optimization target.

Benchmark at a glance

Dataset

The source was a registered industrial-plant E57 export. The project itself is not public, so identifying project details and the original file are not distributed. Reproducibility is supported by publishing the exact file size and SHA-256 fingerprint:

Filename: industrial_plant_registered.e57
Exact size: 28,012,555,264 bytes
Size: 26.089 GiB
Points: 960,078,697
Scans: 39 structured / 0 unstructured
RGB scans: 39
Intensity scans: 39
SHA-256: BCB31A523B2961431635B9AACF1A5ACE984266CC554C1645E5B1F4E15F09C1C6

The E57 also contains 1,205 Image2D blocks. Embedded photos were deliberately disabled for this export test; RGB point attributes remained enabled.

Test system

The benchmark used a normal desktop workstation rather than a dedicated laboratory system:

The GPU is reported for system identification. This benchmark did not record GPU utilization and does not claim GPU acceleration for the measured E57 read or export operations.

Method

The cold-run procedure was designed to keep the result understandable and repeatable:

1. The source SHA-256 was calculated before restarting Windows.
2. Windows was restarted, and the E57 was not opened by another application.
3. CloudCutter performed its required metadata preflight; this was excluded from the timed point-reading operation.
4. The benchmark record was configured as Cold start after Windows reboot.
5. The predetermined mode Progressive preview + exact background refinement was started once.
6. Selections were created and saved while refinement was still running.
7. One split-export command created 20 E57 files with RGB enabled and embedded photos disabled.
8. CloudCutter performed automatic output validation.
9. A high-density output and a very low-density output were opened independently in CloudCompare.

The complete CloudCutter window and the input/output folders were recorded during the measured workflow.

Read-stage result

The first recorded selection action occurred approximately 2 minutes 33 seconds after the timed read began. The initial preview stage completed at approximately 3 minutes 56 seconds, and exact background refinement of all 960 million points completed at approximately 13 minutes 15 seconds.

This distinction is important: productive selection work began before the complete point stream had been refined.

Measured read-stage characteristics were:

• approximately 1.21 million points per second;
• 23.014 GiB of process-level reads;
• peak private memory of approximately 1.66 GiB;
• peak working set below 0.39 GiB.

The benchmark report currently labels the initial-preview completion field as first_interactive_preview. The operator event shows that interaction started earlier, so this label will be corrected in a future benchmark-report revision.

Export result

One user export operation created 20 separate RGB E57 files from the saved selections:

• total exported points: 935,079,030;
• total output size: 16.623 GiB;
• export duration: 1 hour 30 minutes 7 seconds;
• process-level logical reads during export: 461.496 GiB;
• process-level writes during export: 17.605 GiB;
• peak private memory during export: approximately 0.50 GiB.

This result means that CloudCutter can perform the requested large split without a RAM spike. It does not mean that the 20 files are currently written from one source pass.

Output validation

CloudCutter opened all 20 generated files through libE57, read their metadata and Data3D point counts, and compared the combined output point count with the exporter result:

Expected files: 20
Discovered files: 20
Parser-opened files: 20
Validated files: 20
Export helper point total: 935,079,030
Output metadata point total: 935,079,030
Result: 20/20 files passed

Automatic metadata and point-count validation is not the same as decoding and visually checking every point payload. For an independent sanity check, two deliberately different outputs were opened in CloudCompare:

• top_06: a very high-density output;
• top_18: a very low-density output.

Both files opened correctly and contained RGB data as expected. This checks two opposite output-density cases and complements the automatic validator.

The most important finding: read amplification

The read stage consumed approximately 23.014 GiB of process-level input. The 20-file export consumed approximately 461.496 GiB:

461.496 / 23.014 = 20.05

The ratio corresponds almost exactly to one source point-stream pass for each of the 20 output files.

This is the main limitation revealed by Benchmark E57-01. The current safe exporter is memory-efficient and produces valid results, but its read cost grows approximately with the number of output selections. Low-density outputs still require another complete source pass.

The next exporter architecture will therefore target:

1. one sequential pass through the source point stream;
2. indexed routing from each point or tile to the relevant output jobs;
3. bounded per-output buffers;
4. preservation of RGB, intensity and required E57 schema fields;
5. transactional output handling and validation of every completed file.

The objective is not merely to add threads. The primary objective is to eliminate unnecessary source rereads while preserving correctness and bounded memory use.

Repeated-run interpretation

The repeated run reproduced the same per-file point counts, file sizes and Data3D counts. It is therefore useful evidence of functional repeatability.

It did not demonstrate a warm-cache speed advantage, so no such claim is made. A Windows Snipping Tool cursor-performance problem was also identified during the repeated-run recording workflow and subsequently resolved. Because capture behavior can affect operator timing, the repeated result is treated as a reproducibility check rather than a clean cache-performance conclusion.

What this benchmark proves—and what it does not

Supported by the current evidence

• CloudCutter read and refined a 26.09 GiB registered E57 containing 960 million points.
• Selection work began before full refinement completed.
• One user command created 20 RGB E57 output files.
• All 20 outputs passed automatic libE57 metadata and point-count validation.
• Dense and sparse outputs opened independently in CloudCompare with RGB.
• Memory consumption remained bounded and far below the input-file size.
• Export currently performs approximately one source point-stream pass per output.

Not claimed by this test

• superiority over another commercial product;
• a universal performance figure for every E57 dataset;
• warm-cache acceleration;
• single-pass simultaneous export in the current version;
• automatic decoding and verification of every RGB payload value;
• preservation of the original structured-scan topology in every output.

Next steps

Before changing the exporter, one substantially larger E57 will be tested with the current build. This will extend the baseline and show whether the same bottleneck remains dominant at a larger scale.

The planned sequence is:

1. complete Benchmark E57-02 with a larger source;
2. finalize a reproducible selection-manifest format;
3. implement the single-pass multi-output path in the correspondence branch;
4. strengthen payload validation and benchmark event naming;
5. repeat the same datasets and selections after optimization;
6. publish the before/after results, including any regressions or unresolved limitations.

Performance history is most useful when unsuccessful experiments and discovered limitations are recorded together with improvements. This series will therefore remain an engineering log rather than a collection of isolated promotional numbers.

Reports and recordings

For technical questions, validation datasets or collaboration: [email protected]

Publication history