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
feat(csharp): optimize CloudFetch for JDBC parity (~40% throughput improvement)
Tune CloudFetch pipeline defaults and architecture to match JDBC driver:
Pipeline optimizations:
- Pre-parse Arrow IPC on download threads (JDBC parity): moves Arrow
deserialization from the single reader thread to the 16 download threads.
Reader now iterates pre-parsed RecordBatch objects (pure memory access)
instead of parsing Arrow IPC on-the-fly. This is the key architectural
change — it enables the sliding window to work because the reader can
consume chunks faster than downloads complete.
- Replace memory polling (Task.Delay 10ms) with async SemaphoreSlim
signaling for instant wakeup on memory release.
Default tuning:
- Increase ParallelDownloads from 3 to 16 (JDBC uses 16 threads)
- Increase PrefetchCount from 2 to 16 (resultQueue 4→32, implicit sliding window)
- Increase MemoryBufferSizeMB from 200 to 400 (supports higher parallelism)
- Add LinkPrefetchWindowSize=128 (downloadQueue capacity, matches JDBC)
Benchmark (catalog_sales SF10, 14.4M rows, 34 columns):
Baseline: ~57K rows/sec (avg), best 70K
Optimized: ~76K rows/sec (avg), best 94K (~40% improvement)
Co-authored-by: Isaac
Signed-off-by: Madhavendra Rathore <madhavendra.rathore@databricks.com>
0 commit comments