You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/performance/SQLITE_COMPARISON.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,15 +21,15 @@ This report documents the head-to-head performance comparison between the `cloud
21
21
## 4. Architectural Analysis
22
22
23
23
### Point Inserts
24
-
The 7.1x gap in insertion speed is attributed to:
25
-
1.**Statement Parsing Overhead**: Our benchmark currently re-parses SQL strings for every `INSERT` in `cloudSQL`, whereas SQLite uses a prepared statement (`sqlite3_prepare_v2`).
26
-
2.**Object Allocations**: `cloudSQL` allocates multiple `std::unique_ptr` objects (Statements, Expressions, Tuples) per row. SQLite uses a specialized register-based virtual machine with minimal allocations.
27
-
3.**Storage Engine Maturity**: SQLite's B-Tree implementation is highly optimized for write-ahead logging and paged I/O compared to our current Heap Table.
24
+
Following our latest optimizations, `cloudSQL` completely bridged the insert gap and is now **~58x faster** than SQLite. The dramatic inversion in performance is attributed to:
25
+
1.**Prepared Statement Execution**: `cloudSQL` benchmarks now correctly cache and reuse prepared insert statements matching SQLite's `sqlite3_prepare_v2` approach, completely skipping re-parsing overheads per row.
3.**In-Memory Architecture**: This configuration allows `cloudSQL` to behave as a massive unhindered memory bump-allocator, whereas SQLite still respects basic transactional boundaries even with `PRAGMA synchronous=OFF`.
28
28
29
29
### Sequential Scans
30
-
The 6.5x gap in scan speed is attributed to:
30
+
We reduced the scan gap from 6.5x down to **4.0x** slower than SQLite. The remaining gap is attributed to:
31
31
1.**Volcano Model Overhead**: `cloudSQL` uses a tuple-at-a-time iterator model with virtual function calls for `next()`.
32
-
2.**Value Type Overhead**: Our `common::Value` class uses `std::variant`, which introduces a small overhead for every column access compared to SQLite's raw buffer indexing.
32
+
2.**Value Type Allocations**: Scanning in `cloudSQL` fundamentally builds `std::pmr::vector<common::Value>` using `std::variant` properties for each row, constructing dense memory structures. SQLite's cursor is highly optimized to avoid unnecessary buffer copying unless columns are fetched.
33
33
34
34
## 5. Post-Optimization Enhancements
35
35
We addressed the gaps via the following optimizations:
0 commit comments