For me when it comes to the performance of standard data structures and algorithms and memory allocators (and the only reason to use one or the other typically is for performance), they're pretty easy to beat if your solution is less generalized than the standard library, and it's almost impossible to beat when you try to fulfill the exact same requirements.
As an example, it's very difficult to beat
std::sort in C++ if you want a generalized comparison-sort (at least unless you use a parallelized version). However, you can easily beat
std::sort if you use even a naive radix sort which only operates on integers or pointers.
Likewise you'll generally be hard-pressed beating the efficiency of C's
malloc if you want a general-purpose thread-safe allocator that can handle variable-sized allocations and free individual chunks of memory. But you can easily beat it if you use a free list which can only pool chunks of a specific size and is only designed to be used from one thread at a time, or a sequential allocator which just pools in a straight sequential fashion and doesn't offer the ability to free chunks individually.
It'll be extremely difficult, if not impossible, to beat
std::vector in C++ in all cases while fulfilling identical requirements. But it's easy enough to beat it for a sequence that's specifically optimized to store only, say, 0 to 8 elements.
HandRolledArrayList<Float> is unlikely to outperform
ArrayList<Float> in Java. But you can easily outperform it if you just use an array of
And if you're working in a truly performance-critical area where you're looping over millions of things and/or discovered hotspots through measuring, then it can sometimes pay to implement a competing data structure or allocator or algorithm to what's provided in the standard library, but typically only if your implementation is far less generally-applicable than the requirements the standard library implementers had to fulfill.