Pedagogical quicksort vs. introsort hybrid for latency-sensitive sorting in production

Context

The Algorithms repository provides clean, well-commented quicksort implementations across 30+ languages, but its contribution guidelines explicitly prioritize readability over micro-optimizations. The naive pivot selection and recursive structure degrade to O(n²) on already-sorted or duplicate-heavy input, and CI only verifies correctness—not worst-case complexity or performance regressions.

Constraint

A latency-sensitive service must sort user-supplied datasets where adversarial input (pre-sorted, reverse-sorted, many duplicates) is realistic. Copying the repository’s quicksort directly risks predictable stack overflows and quadratic latency spikes, yet the repo lacks a “production-ready” tag, optimized branch, or complexity annotations to guide selection.

Trade-off

Two documented approaches exist: (1) adopt the pedagogical implementation and add external guards (recursion-depth limit, fallback to heapsort), preserving code clarity and upstream sync; or (2) replace it with a language-standard introsort/Timsort hybrid (e.g., std::sort, Arrays.sort, CPython’s list.sort) that guarantees O(n log n) worst-case but diverges from the repository’s educational intent and contribution model.

Questions

1. When integrating sorting from this repo into a production path, is wrapping the naive quicksort with a depth-limited introsort fallback more maintainable than switching entirely to the platform’s built-in hybrid sort?
2. Does the repository’s issue history reveal any accepted pattern for annotating asymptotic bounds or marking implementations as “not production-hardened” without forking?
3. How do teams currently validate worst-case behavior when the upstream CI lacks benchmark or complexity-check steps?