Global mapper slowdown on a 1,002-image THIN_PRISM_FISHEYE rig dataset compared with legacy COLMAP + GLOMAP

Observation

I am evaluating COLMAP's integrated global_mapper as a replacement for my older workflow consisting of COLMAP feature extraction/matching followed by a separate CUDA-enabled GLOMAP executable.

On my 1,002-image dataset, the more comparable integrated configuration takes 22:10.83 instead of 15:56.14 for the SfM stages (+39.2%). The mapper alone takes 1,160.72 instead of 863.34 seconds (+34.4%). Much of the extra mapper time is in retriangulation/refinement.

This is an observed workflow slowdown, not yet a controlled or bisected COLMAP regression. My legacy executable is a local CUDA-enabled build, not a verified pristine upstream reference. Matching, optimization scope, threading, dependencies and execution environment are not fully identical.

I am withholding my private camera setup, initialization, variable-selection details and pipeline commands. The omission limits reproducibility; it must not be interpreted as use of identical settings or defaults.

This differs from my earlier closed issue #4437, which concerned extraction/matching in COLMAP 4.0.4. This report focuses on global-mapper refinement at commit 9fdaf93ba4bc71a704fffadc4ed7cf1d9cf55de8. CASPAR is disabled; BA uses Ceres.

Environment

• Ubuntu 24.04.4 LTS; NVIDIA RTX 3090 with 24 GB VRAM; 16 physical CPU cores / 32 logical CPUs; approximately 64 GB RAM.
• COLMAP 4.2.0.dev0, commit 9fdaf93ba4bc71a704fffadc4ed7cf1d9cf55de8; not a claim about today's latest main.
• Release build, CUDA toolkit 12.8, Ceres 2.3 with cuDSS support.
• Current runs: explicit GlobalMapper.num_threads=8, OMP_NUM_THREADS=8, OPENBLAS_NUM_THREADS=1; GPU enabled for global positioning and BA.
• I have not verified the effective historical thread count. The presence of 32 logical CPUs does not prove that the historical run used 32 solver threads.

Results on the 1,002-image dataset

These are single runs. SfM total sums extraction, optional setup, matching and mapping; copying, hashing and model inspection are excluded. Configuration A is the closer workflow comparison with the legacy run; configuration B has a different optimization contract. Configuration labels do not imply equivalent work.

The totals include 3.44 s of setup for the legacy run and 3.89 s for configuration A.

The point and observation sets differ. These mean errors are not a matched-observation accuracy comparison and do not establish degraded geometry. All reported BAs in the two completed integrated runs terminate with CONVERGENCE.

The two integrated profiles also have the following references on a separate 200-image dataset:

Where the mapper time goes

Legacy timing excludes double-counting overlapping nested timers. Phase implementations and optimization scopes are not identical. In configuration A, retriangulation/refinement contributes approximately 267 seconds of additional time and accounts for 66% of mapper wall time.

At the tested commit, GlobalMapperOptions fixes SPARSE_SCHUR and disables automatic solver selection. I am not attributing this to a size-triggered dense-to-sparse switch.

The relevant upstream refinement code is IterativeRetriangulateAndRefine. I have not isolated the additional cost of its optimization scope from numerical-library or threading effects.

Diagnostic status at submission

A subsequent matching configuration took 61.91 s instead of 132.21 s. This indicates that the original matching timings should not be treated as equivalent-work performance measurements. Its 8-thread mapper completed with exit code 0 in 1,137.69 s; quality analysis and the paired 16-thread run were not complete at submission.

That diagnostic uses fresh features and --log_level 3, so it is not a clean A/B against the earlier table. The separate 8/16-thread comparison uses byte-identical copies of one prepared database, the same binary and logging, with OpenMP/BLAS settings fixed. I do not yet claim a thread-scaling result.

The diagnostic Ceres report confirms:

Sparse linear algebra library     CUDA_SPARSE + AMD
Linear solver                    SPARSE_SCHUR             SPARSE_SCHUR
Threads                                     8                        8

Questions

1. What profiling information beyond Ceres FullReport would best separate Jacobian evaluation, Schur construction, ordering, factorization, transfers and other costs in global-mapper refinement?
2. Are there known performance issues at this commit, or recommended threading settings for GPU sparse BA?
3. How should I establish a comparable optimization workload between standalone GLOMAP and the integrated global mapper before interpreting the difference as a regression?

I have retained raw logs and output models locally. I have not attached private images, databases or my detailed reconstruction recipe. This report establishes an observed slowdown in my workflow, not a minimal public reproducer or a proven quality-neutral fix.