Skip to content

(Improvements) Ring-buffer and XdrReaderWriter optimizations, assorted Span/Memory method additions - #1253

Open
pl752 wants to merge 3 commits into
FirebirdSQL:masterfrom
pl752:span_opt_1
Open

(Improvements) Ring-buffer and XdrReaderWriter optimizations, assorted Span/Memory method additions#1253
pl752 wants to merge 3 commits into
FirebirdSQL:masterfrom
pl752:span_opt_1

Conversation

@pl752

@pl752pl752 commented Dec 29, 2025

Copy link
Copy Markdown
Contributor

Decided to split up my previous pull request (#1247) to multiple PRs due to it having set of changes too broad in my opinion. Ran tests as usual for fb3 server and embedded. Updated to current master branch state. Also decided to throw in reworked ring-buffer Queue's to be more large object friendly.

TLDR: Ellimination of most of the repeated allocations for intermediate conversions, also added inplace copy methods for I/O and reworked intermediate network buffers to use proper ring-buffer resizable arrays with unitary copying instead of per-byte queueing, massively boosting large objects throughput.

Practical benchmarks (3 int and 1 char100 columns, real I/O with fb3 server on localhost and nvme)

Master:

MethodRowsMeanErrorStdDevMedianGen0Gen1Allocated
SelectAndMap_Main_ReusedBufferAsync101.796 ms0.0649 ms0.1904 ms1.784 ms--457.27 KB
SelectAndMap_Main_ReusedBufferAsync1008.326 ms0.5724 ms1.5955 ms7.472 ms--4502.13 KB
SelectAndMap_Main_ReusedBufferAsync100031.037 ms3.7512 ms10.8231 ms24.973 ms5000.00001000.000044985.72 KB
SelectAndMap_Main_ReusedBufferAsync10000337.278 ms16.5461 ms48.7865 ms334.254 ms55000.000010000.0000449543.01 KB
SelectAndMap_Main_ReusedBufferAsync1000003,467.848 ms98.9785 ms288.7249 ms3,435.619 ms550000.0000114000.00004494685.62 KB

New (isolated from Rune opt (#1252)):

MethodRowsMeanErrorStdDevMedianGen0Gen1Allocated
SelectAndMap_Main_ReusedBufferAsync101.614 ms0.0500 ms0.1450 ms1.584 ms--447 KB
SelectAndMap_Main_ReusedBufferAsync1009.760 ms0.1127 ms0.0880 ms9.746 ms--4411.49 KB
SelectAndMap_Main_ReusedBufferAsync100022.283 ms2.1941 ms6.1524 ms19.432 ms5000.00001000.000043999.39 KB
SelectAndMap_Main_ReusedBufferAsync10000221.000 ms9.0103 ms26.1406 ms221.383 ms53000.000010000.0000439534.85 KB
SelectAndMap_Main_ReusedBufferAsync1000002,317.527 ms46.2359 ms108.0750 ms2,342.930 ms538000.0000108000.00004394711.29 KB

Combined with #1252:

MethodRowsMeanErrorStdDevMedianGen0Gen1Allocated
SelectAndMap_Main_ReusedBufferAsync10471.8 us15.22 us43.68 us462.0 us--43.98 KB
SelectAndMap_Main_ReusedBufferAsync1001,638.7 us62.67 us182.81 us1,590.5 us--383.96 KB
SelectAndMap_Main_ReusedBufferAsync100013,283.3 us2,299.73 us6,561.26 us9,672.6 us--3785.55 KB
SelectAndMap_Main_ReusedBufferAsync1000092,663.6 us2,673.87 us7,841.99 us91,372.1 us4000.0000-37583.41 KB
SelectAndMap_Main_ReusedBufferAsync100000897,179.0 us17,724.27 us24,846.95 us900,061.5 us45000.00005000.0000375392.09 KB

Perf (defaults):

MethodJobBuildConfigurationDataTypeCountMeanErrorStdDevRatioRatioSDGen0AllocatedAlloc Ratio
ExecuteNuGetReleaseNuGetbigint10019,426.6 us195.03 us172.89 us1.000.0131.2500290.31 KB1.00
ExecuteProjectReleasebigint10019,731.2 us376.18 us369.46 us1.020.02-192.32 KB0.66
FetchNuGetReleaseNuGetbigint100461.9 us5.48 us5.12 us1.000.025.859452.02 KB1.00
FetchProjectReleasebigint100449.6 us3.00 us2.81 us0.970.013.906339.03 KB0.75
ExecuteNuGetReleaseNuGetvarch(...) utf8 [30]10019,592.1 us172.88 us144.36 us1.000.0131.2500294.24 KB1.00
ExecuteProjectReleasevarch(...) utf8 [30]10019,419.8 us96.03 us80.19 us0.990.01-194.64 KB0.66
FetchNuGetReleaseNuGetvarch(...) utf8 [30]100466.2 us2.37 us2.22 us1.000.016.835955.9 KB1.00
FetchProjectReleasevarch(...) utf8 [30]100458.4 us3.01 us2.67 us0.980.013.906339.77 KB0.71

Boost for large object I/O is significant. Benchmarks were performed without compression and encryption (typical for walled LAN / server sharing db with apps in single env). For small data types and writing operations, changes in practice are much smaller, but some difference in allocations can be observed still. Such an effect on performance is mostly due to ellimination of copies and ability for system to use packed operations (r/w with 64 bit ops instead of 8x8 bit ops) or even simd when dealing with the buffers, and also jit should be much happier with the new installment. For large blobs with the same mode boost can be even bigger with the bypass mode (less copies).

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@pl752