Ruby XLSX Ecosystem & Peer Libraries

The Ruby ecosystem is fortunate to have a rich set of mature, well-engineered XLSX libraries. Each library represents deliberate architectural choices tailored for specific problem spaces.

This document provides a respectful overview of the peer libraries in the Ruby ecosystem, explains the underlying engineering tradeoffs (such as Streaming vs. In-Memory and Shared String Tables vs. Inline Strings), and shares comprehensive benchmark measurements.

The Peer Libraries

Architectural Tradeoffs

Spreadsheet libraries must balance multiple competing dimensions: memory consumption, execution speed, formatting capabilities, and strict specification compliance.

1. Memory & Execution Model: Streaming vs. In-Memory

┌─────────────────────────────────────────────────────────────┐
│                      Execution Models                       │
├──────────────────────────────┬──────────────────────────────┤
│       Streaming Model        │       In-Memory Model        │
├──────────────────────────────┼──────────────────────────────┤
│ • Processes rows on-the-fly  │ • Builds complete DOM tree   │
│ • O(1) constant RAM footprint│ • Enables random cell access │
│ • Cannot seek backward       │ • High RAM on large datasets │
│ • Ideal for batch exports/ETL│ • Ideal for templates/edits  │
└──────────────────────────────┴──────────────────────────────┘

• Streaming Model (xlsxrb, xlsxtream, simple_xlsx_reader, roo, creek, xsv): Rows and cells are processed sequentially and flushed/discarded immediately. This keeps memory usage completely flat and predictable, regardless of whether the file has 10 rows or 1,000,000 rows. However, random access (e.g., modifying cell("A1") after writing row 100) is not possible.

• In-Memory Model (xlsxrb, caxlsx, write_xlsx, rubyXL): The entire workbook structure is parsed into Ruby objects, providing complete flexibility to inspect, modify, insert, or reorder cells and worksheets. The tradeoff is that memory consumption scales with the number of cells.

2. String Storage Architecture: Shared String Table (SST) vs. Inline Strings

The OpenXML (ECMA-376) specification defines two ways to store text in cells:

<!-- 1. Shared String Table (SST): Deduplicated dictionary reference -->
<c r="A1" t="s"><v>0</v></c>

<!-- 2. Inline String: Raw text payload inside the cell -->
<c r="A1" t="inlineStr"><is><t>Hello World</t></is></c>

Shared String Table (SST)

• How it works: Strings across all worksheets are collected into a single central dictionary (xl/sharedStrings.xml). Cells only store numeric integer IDs pointing to dictionary entries.

• Strengths:

• Smaller file footprint: Deduplication significantly reduces the uncompressed XML size (typically 50% to 80% smaller for business datasets with repetitive categories, statuses, dates, and labels).

• Standard Microsoft Excel behavior: Excel defaults to SST. Opening SST-based spreadsheets in Excel consumes less memory and renders faster.

• Rich Text & Shared Styles: Supports rich text formatting within strings.

• Tradeoff:

• Writing requires managing a string table dictionary or making a multi-pass serialization, adding slight CPU overhead during generation.

Inline Strings

• How it works: Text is written directly into each <c> element (<is><t>...</t></is>) as the stream proceeds.

• Strengths:

• Raw Throughput: Bypassing string deduplication allows immediate row-by-row flushing with minimal CPU overhead (as demonstrated by xlsxtream).

• Tradeoff:

• Produces significantly larger raw XML files when strings repeat, and some third-party spreadsheet viewers or legacy tools have limited support for inline strings compared to SST.

Detailed Benchmark Results

The following benchmarks evaluate processing 1,000,000 cells (100,000 rows × 10 columns) containing standard business data (integers, strings, floats, booleans, and dates) across 3 isolated subprocess runs.

Write Performance (1,000,000 cells)

Read Performance (1,000,000 cells)

Reproducing Benchmarks Locally

The benchmark suite leverages bundler/inline to run each library in an isolated subprocess (Bundler.with_unbundled_env), eliminating cross-gem pollution and ensuring accurate memory measurements.

To run the suite on your machine:

ruby benchmark.rb 100000 10