[rpms/unixODBC] rawhide: [performance] Enable '--enable-fastvalidate' to eliminate O(n) handle validation overhead

[rpms/unixODBC] rawhide: [performance] Enable '--enable-fastvalidate' to eliminate O(n) handle validation overhead

[Michal Schorm]

            A new commit has been pushed.

            Repo   : rpms/unixODBC
            Branch : rawhide
            Commit : ce621dc9aa1f6dc86ac099501c192b767fb1be2e
            Author : Michal Schorm <mschorm@redhat.com>
            Date   : 2026-06-26T15:42:23+02:00
            Stats  : +1/-0 in 1 file(s)
            URL    : https://src.fedoraproject.org/rpms/unixODBC/c/ce621dc9aa1f6dc86ac099501c192b767fb1be2e?branch=rawhide

            Log:
            [performance] Enable '--enable-fastvalidate' to eliminate O(n) handle validation overhead

Without '--enable-fastvalidate', unixODBC validates every handle on every ODBC
API call by traversing a global linked list under a global mutex
('mutex_lists'). This is O(n) where n = total statement handles across all
connections, and the mutex serializes all threads. At scale (40+ concurrent
connections), aggregate cost grows as O(n^2) and dominates CPU time.

With '--enable-fastvalidate', handle validation becomes an O(1) magic-number
check with no locking. Per-connection statement iteration also switches from
global list filtering to per-connection linked lists.

Benchmark (Fedora Rawhide container, SQLite ODBC, best of 3 runs):

  Single-threaded — shows O(n) vs O(1) validation cost:

    Handles  Baseline ops/s  Fastvalidate ops/s  Speedup
        100       1,798,402           2,265,627    1.26x
      1,000         595,311           2,062,712    3.46x
      5,000         145,776           1,734,585   11.90x
     10,000          74,486           1,494,915   20.07x

  Multi-threaded — shows additional mutex contention:

    Handles  Threads  Baseline ops/s  Fastvalidate ops/s  Speedup
      5,000        4         134,947           1,171,034    8.68x
     10,000        4          69,269           1,174,854   16.96x
      5,000        8         128,174             983,613    7.67x
     10,000        8          66,955             984,302   14.70x
      5,000       16         120,639             602,676    5.00x
     10,000       16          66,279             598,478    9.03x

Baseline throughput drops 24x as handles scale from 100 to 10,000 (O(n)
validation), and flatlines with more threads — the global mutex serializes
all concurrent access. Fastvalidate stays nearly flat across handle counts
and scales with threads until cache contention dominates.

Tradeoff: the fast path uses a magic-number check instead of walking the
global list. It won't catch use-after-free of handles — but passing freed
handles is an application bug that causes undefined behavior regardless.

Driver name resolution via 'odbcinst.ini' confirmed working correctly with
fastvalidate (tested with 'isql' + SQLite driver in container — all 6
registered drivers visible, connection successful via driver name).

Cross-distribution precedent:
- Debian: enabled since 2017 (v2.3.4-1.1), motivated by Debian #819622
- Ubuntu: inherited from Debian
- openSUSE/SUSE: enabled since 2017 (bnc#1044970)

Resolves: RHEL-112733

Co-Authored-By: Claude AI <noreply@anthropic.com>

---
diff --git a/unixODBC.spec b/unixODBC.spec
index f5d213b..b0c58ae 100644
--- a/unixODBC.spec
+++ b/unixODBC.spec
@@ -59,6 +59,7 @@ autoreconf -vfi
 %configure \
   --with-gnu-ld=yes \
   --enable-threads=yes \
+  --enable-fastvalidate \
   --enable-drivers=no \
   --with-odbc-driver-path=%{_libdir}/odbc \
 %if %{with gui_related_parts}