perf(msexcel): replace O(n) merge-cell scan with O(1) spatial index#3808
Open
TongLing916 wants to merge 1 commit into
Open
perf(msexcel): replace O(n) merge-cell scan with O(1) spatial index#3808TongLing916 wants to merge 1 commit into
TongLing916 wants to merge 1 commit into
Conversation
Contributor
|
✅ DCO Check Passed Thanks @TongLing916, all your commits are properly signed off. 🎉 |
Contributor
Merge Protections🟢 Merge protection satisfied — ready to merge. Show 1 satisfied protection🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
|
The _find_table_bounds BFS flood-fill and Phase 2 data extraction both did linear scans over sheet.merged_cells.ranges for EVERY cell visited, resulting in O(cells × merge_regions) complexity. On documents with thousands of merge regions (e.g. A3 engineering spec sheets), this caused 40+ minute parse times on ~21k cells — while a flat Orders.xlsx with 4x more cells parsed in 4.5 seconds. Changes: - Pre-build merge_top_left dict, merge_all_cells set, and hidden_merge_cells set once per sheet in _find_data_tables. - has_content() now does O(1) set lookup instead of iterating all ranges. - Phase 2 row_span/col_span uses O(1) dict get instead of linear scan. - When two merge ranges share the same top-left (pathological), the first wins, matching the old break-on-first-match behaviour. Benchmark (380 merges, 9400 cells): 423x speedup, output identical. Benchmark (4079 merges, 72600 cells): 0.57s (old path would be ~hours). Signed-off-by: Tong Ling <ling_tong@outlook.com>
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.
The _find_table_bounds BFS flood-fill and Phase 2 data extraction both did linear scans over sheet.merged_cells.ranges for EVERY cell visited, resulting in O(cells × merge_regions) complexity.
On documents with thousands of merge regions (e.g. A3 engineering spec sheets), this caused 40+ minute parse times on ~21k cells — while a flat Orders.xlsx with 4x more cells parsed in 4.5 seconds.
Changes:
Benchmark (380 merges, 9400 cells): 423x speedup, output identical.
Benchmark (4079 merges, 72600 cells): 0.57s (old path would be ~hours).
Checklist: