Conversation
lidar_odometry_step_1 loads every raw point-cloud file before step 1 starts, and step 2's map buffer (points_global) only shrinks at a sliding-window reset. A long recording from a slow-moving platform (~50 min, ~29,000 frames) needs more than 60 GB of RAM and the run is killed part-way. Two parameters in the [performance] section of LidarOdometryParams, saved with every run and documented in doc/virtual_memory.md: - lazy_load_raw_clouds (default true): each raw file is loaded when step 1 reaches its time range and freed once step 1 has passed it. Files are loaded and sorted exactly as before, so step 1 sees the same points in the same order. The raw data viewer sets it to false and keeps every file. - points_global_spill_directory (default "", in memory): when set, step 2's map buffer is kept in a temporary file there, owned by the compute_step_2 call, and streamed back in order at a reset with the ray-cast decision of its whole size. An I/O error ends step 2 with an error (no abort) and the files are removed on every exit; the final close is checked. Lazy loading reads each file twice and refuses a file that changed in between (size, modification time before and after the read, point count, time range). The step 1 GUI, its console mode and the precision-forestry app now act on a failed step 1 or step 2: the console reports "no results saved" and exits 1, and the GUI neither marks the step done nor saves a partial result. Also: the two 101^3 normal-vector histograms are cleared by resetting only the bins written in the previous iteration; the raw clouds are released after a successful step 1 (release_raw_clouds: run_lidar_odometry, the step 1 GUI and console, the precision-forestry app), since nothing later reads them; both parameters are exposed in the Python bindings. Heap trimming is glibc-only; file seeks are 64-bit (_fseeki64 / fseeko, range-checked where off_t is narrower). Every trajectory, scan and pose file is byte-identical to the unpatched build on a recording window, with the defaults, lazy loading off, the spill directory set, and resets forced by a 20 m window; only metadata differs. (When the per-frame time limit real_time_threshold_seconds is reached, the iteration count depends on machine speed with or without this change.) Peak memory there: 2.2 GB unpatched, 1.3 GB with the defaults, 0.75 GB with the spill directory set. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
adamdbrw
changed the title
michalpelka
self-requested a review
October 5, 2026 14:38
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Process long recordings without running out of memory
Now you can run lidar odometry on long recordings — an hour of walking, or a slow vehicle — on an ordinary
workstation. Before, such a run could need more than 60 GB of RAM and be killed part-way.
Now you can keep the map's working buffer on disk instead of in RAM, with one line in the parameter file.
The results are exactly the same as before: same trajectory, same scans, same poses, byte for byte.
How
Raw scans are now loaded when they are needed and freed when they are done, instead of all at once at the start.
This is on by default and already lowers memory use (2.2 GB → 1.3 GB on our test).
For very long recordings, set a scratch folder and the map buffer lives there (→ 0.75 GB on the same test):
Both settings are documented in
doc/virtual_memory.md. If a step fails, for example when the disk is full, the appsnow report the error instead of saving a partial result.