Question 1

How accurate are the 34-second and 26-second benchmarks for 10M rows?

Accepted Answer

Benchmarks were conducted internally in February 2026 on Chrome 132 (stable), Windows 11, Intel Core i7-12700K (3.6GHz, 12 cores), 32GB DDR4-3200 RAM. Advanced mode: 10M rows with 19 functions applied (MEDIAN, P90, P95, STDDEV, VARIANCE, COUNT_DISTINCT, plus the 5 basic functions). Simple mode: 10M rows with COUNT, SUM, AVG, MIN, MAX only. Both used 5 GROUP BY dimensions on a synthetic 1.2GB CSV with mixed data types. 10 runs per configuration with highest and lowest discarded, remaining 8 averaged. Results vary ±15–20% depending on browser, available RAM, number of GROUP BY dimensions, cardinality, and which functions are selected. Simple mode is faster because it avoids value-storage arrays required by MEDIAN, percentiles, MODE, and FIRST/LAST.

Question 2

Why is advanced mode slower than simple mode?

Accepted Answer

Simple mode functions (COUNT, SUM, AVG, MIN, MAX) are computed online using running totals — O(1) memory per group, no storage of individual values. Advanced mode functions require storing actual values per group: MEDIAN and percentiles (P25–P95) need all values in a group to compute the true median/percentile; MODE needs value frequency counts; FIRST/LAST need sort-order tracking; CONCAT_UNIQUE needs a Set of all unique text values. For 10M rows split across 500 groups with 20K values per group, the MEDIAN-tracking arrays alone add hundreds of megabytes of RAM allocation — which also triggers more garbage collection. The trade-off is accuracy: true MEDIAN vs AVERAGE, real P95 vs approximation.

Question 3

Why does performance improve with larger files (1K rows is slower than 10M)?

Accepted Answer

Small files carry proportionally more startup overhead: Web Worker initialization, PapaParse setup, file reading into memory, and output assembly all cost a fixed time regardless of file size. At 10M rows, the 10MB chunk batching architecture reaches full pipeline efficiency — chunks are always ready, string interning reduces allocation pressure, and the fixed startup cost is amortized across 10 million rows. This is why 1K rows shows ~25K rows/sec while 10M rows achieves ~380K rows/sec in simple mode.

Question 4

How does this compare to Excel Pivot Tables at scale?

Accepted Answer

Excel Pivot Tables often become slow or memory-constrained between 300K–500K rows depending on system RAM and workbook complexity. At 500K rows with 3+ GROUP BY dimensions: Excel typically takes 45–120 seconds and may freeze or crash. SplitForge processes 500K rows in ~1.3 seconds (simple mode) or ~1.9 seconds (advanced mode). At 10M rows: Excel has a hard worksheet row limit of 1,048,576 rows — the file cannot be opened in its entirety. SplitForge processes 10M rows in 26–34 seconds. The performance advantage is structural — Excel allocates all data into a worksheet grid; SplitForge streams data through a pipeline without materializing the full dataset in UI memory.

Question 5

What happens with high-cardinality GROUP BY columns?

Accepted Answer

Group count directly affects memory usage. 100 groups at 10M rows = 100 HashMap entries (fast, low memory). 10M groups at 10M rows = 10M HashMap entries (essentially no grouping — each row is its own group). High cardinality dramatically increases memory and may slow processing by 30–50% due to HashMap collision resolution and GC pressure. Rule of thumb: if your GROUP BY column has cardinality > 50% of row count, you're probably not aggregating meaningfully. Count distinct values in your column before selecting it as a GROUP BY dimension — the Data Profiler can do this before you aggregate.

Question 6

Does the HAVING filter affect processing speed?

Accepted Answer

Negligible impact during aggregation. HAVING filters are applied after all groups are computed, not during streaming. The filter pass scans each group once — O(n_groups) not O(n_rows). For 500 groups, HAVING evaluation adds under 1 millisecond. The one exception: HAVING filters that reference MEDIAN or percentile functions require those values to be materialized (which is already done in advanced mode). In simple mode, adding a HAVING filter on AVG is instant; adding one on MEDIAN would require switching to advanced mode, which incurs the full advanced-mode overhead.

Question 7

What's the maximum file size SplitForge can handle?

Accepted Answer

Practically ~1–1.5GB on most modern machines (16GB+ RAM, Chrome or Edge). The limit is available browser RAM, not a hard-coded ceiling. SplitForge uses streaming 10MB chunk processing — it never loads the entire file into memory at once. However, the GROUP BY HashMap grows with the number of unique group combinations × functions selected. High-group-count advanced-mode aggregations at 1.2GB may approach memory limits on machines with 8GB RAM or less. If you see 'out of memory' errors: try simple mode, reduce GROUP BY dimensions, or reduce the number of functions selected.

Question 8

What browser gives the best performance?

Accepted Answer

Chrome and Edge (V8 engine) give the best Web Worker performance — typically 10–15% faster than Firefox (SpiderMonkey) and 20–25% faster than Safari (JavaScriptCore) for CPU-bound operations like aggregation. All benchmarks in this page were run on Chrome 132. Chrome's V8 has highly optimized HashMap operations and string interning that align well with SplitForge's aggregation engine. For best results: Chrome or Edge, latest stable version, with other tabs closed to maximize available RAM.

Question 9

Does SplitForge transmit any file data for analytics?

Accepted Answer

No. All processing occurs in your browser using Web Workers. No file contents, filenames, or row data are ever transmitted to our servers — not during upload, not during processing, and not as part of any analytics event. Usage analytics (aggregate counts, feature flags) contain zero file-derived information. Verifiable: open Chrome DevTools Network tab, upload a CSV, and observe that no file payload appears in outbound requests.

File Size	Simple Mode (5 functions)	Advanced Mode (19 functions)	Notes
1K rows	~25K rows/sec	~18K rows/sec	Startup overhead dominates at small sizes (worker init, file read)
10K rows	~185K rows/sec	~130K rows/sec	Worker pipeline warming up, chunk batching beginning to amortize
100K rows	~310K rows/sec	~210K rows/sec	Typical CRM or financial export batch
1M rows	~390K rows/sec	~265K rows/sec	5 GROUP BY dimensions, 3 metric columns
5M rows	~400K rows/sec	~280K rows/sec	Streaming chunks fully pipelined, peak throughput approaching
10M rowsVerified	~380K rows/sec (~26s)	~294K rows/sec (~34s)	Verified benchmark — peak throughput, memory-bounded at scale
~1.2GB file	~365K rows/sec	~270K rows/sec	Near browser-memory ceiling — results vary significantly by available RAM

Aggregate & Group: Verified Benchmarks. 10 Million Rows in 34 Seconds.

Throughput by File Size — Simple vs Advanced Mode

Rows Per Second — Visual Comparison

Simple Mode — 5 Functions (COUNT, SUM, AVG, MIN, MAX)

Advanced Mode — 19 Functions (includes MEDIAN, Percentiles, STDDEV)

Benchmark Methodology & Test Configuration

Why Browser-Based Aggregation Outperforms Excel on Large Files

What Excel Pivot Tables Do

What SplitForge Does

Time Savings Calculator

Function Performance Characteristics

Honest Limitations: Where Falls Short

Browser-Based Processing

No Offline Mode (Initial Load)

Browser Tab Memory Limits

Frequently Asked Questions