Skip to content

LunivCore Performance Benchmark

The core engine sustained a performance rate consistently in the 32–37 Million Rows Per Second (RPS) range, validating its “C-Level Performance” goal for analytical workloads.


Measure the Rows Per Second (RPS) throughput of the lcore executable when performing a full scan and aggregation (e.g., dataset:sum()) on CSV data.

The benchmarks were run on a CachyOS (Arch-based) environment, utilizing the time ./lcore command to capture wall-clock time and CPU time.


The following table summarizes the performance as the dataset size scaled by a factor of nearly 3,000x (from 5.5K to 11.9M rows).

TestDataset Count (Rows)Executed Time (ms)User Time (ms)System Time (ms)Throughput
15,5081.640.231.47approx 3.3 million rows per second
2396,64713.4611.052.41approx 29.5 million rows per second
33,173,18388.2778.769.14approx 35.9 million rows per second
46,346,367169.73138.6930.48approx 37.4 million rows per second
511,908,037367.70304.1160.99approx 32.4 million rows per second*

The engine consistently sustained a processing rate of 32–37 million rows per second once the initial low-volume I/O overhead was cleared (Test 1).

This performance validates the core decision to build a high-performance analytics engine using C.

The execution time scales nearly linearly with the input size.

For example, doubling the rows from 6.3M to 11.9M resulted in a proportional increase in execution time (169 ms to 367 ms).

This demonstrates a robust O(n) complexity with minimal overhead, suitable for massive datasets.

The breakdown between User Time (program logic) and System Time (I/O) confirms high efficiency:

  • For large datasets (Tests 2–5), the process is CPU-bound (e.g., in Test 5, User Time is approx 5 times greater than System Time).
  • This indicates the bottleneck is the sheer speed of the CPU executing the optimized parsing and calculation logic, not waiting for slow disk I/O.

When loading complex formats like JSON or connecting to SQLite, the overall throughput drops significantly.

This is due to the necessary overhead of complex parsing state machines and database connection latency, confirming that LunivCore’s speed advantage is maximized on flat, streamable data like CSV.