Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

A non-empty spreadsheet cell builds three elements before any html limit applies

オープン
  • 何か問題がありますか？
#781 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
静か
技術スタック
cpp
領域
performance

調査の方向性

Start with ElementRegistry::Sheet::Cell and the pugi::xml_node it already holds, then trace how the registry tree is built and traversed as const. Compare this with sheet_rendered_extent in internal/html/document_element.cpp and the spreadsheet limit settings. Done means distinct non-empty cells no longer eagerly build paragraph/text children while preserving the required element-id and traversal behavior.

索引モデルが issue の本文から書いたものです。

説明

Split out of #762, which #780 otherwise finishes. Numbers are against #780.

odr-private/ods/efficiency-big-1.ods decodes into 3.16M registry elements for
1.05M cells: parse_sheet creates a sheet_cell element and then
parse_any_element_children builds a paragraph and a text for the cell's
<text:p>Genius</text:p>. Every row of that file is the same three cells and the
rows are not number-rows-repeated-compressed, so each one is distinct and
none of the collapsing added in #776 applies.

Empty cells already cost nothing — is_cell_empty registers a range entry with a
null element id and no element at all — and since #776 a repeated cell with
content is one entry too. This is the remaining case: a distinct non-empty
cell, expanded eagerly.

What it costs

Per cell, after #780:
sheet_cell, paragraph, text elements 3 x 32 B
m_sheet_cells entry (position + repeated flag) 16 B
m_texts entry (the run's last node) 16 B
sheet index Cell (range end, element id, node) 16 B
144 B

which is ~150 MB of the 626 MB peak on that file. Making the children lazy is
worth the paragraph, the text and the m_texts entry — ~85 MB — and leaves
~68 MB for the cells themselves.

HtmlConfig::spreadsheet_limit and spreadsheet_cell_limit do not bound any of
it: they are applied in sheet_rendered_extent (internal/html/document_element.cpp),
long after odf::Document's constructor has built the whole tree. A 100-row,
2000-cell budget costs exactly as much as the default one.

Options

  • Lazy children. ElementRegistry::Sheet::Cell already holds the
    pugi::xml_node, so a cell's children can be built on first access. The
    registry is a pre-built tree today and traversal is const, so this needs an
    on-demand builder and a decision about what an element id means before its
    element exists.
  • Bound the parse. Let the cell budget reach decode time so the parser stops
    registering content past it. Cheaper, but it makes the model depend on the
    render config, which the architecture deliberately keeps apart.

The first is the one that generalises: it is the same lifetime question a
streaming decode asks (see the sibling issue), so it is worth doing first and
learning from cheaply.

主要言語
C++
スター
41
フォーク
10
平均マージ
12時間 4分
マージ済み PR（30日）
297

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

opendocument-app/OpenDocument.core のほかの issue

opendocument-app/OpenDocument.core の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。