Which allocator strategy best prevents memory fragmentation in long-running Zig services?

Zig's explicit allocator pattern requires a conscious choice between different memory management strategies depending on the object lifecycle. In a long-running service, the GeneralPurposeAllocator (GPA) provides essential leak detection during development, but its overhead and fragmentation patterns may differ from specialized allocators when handling high-frequency, short-lived requests.

The ArenaAllocator simplifies cleanup by allowing bulk deallocation, but it is typically tied to a specific task's scope. Conversely, the FixedBufferAllocator eliminates heap overhead by using a pre-allocated slice, though it imposes a strict memory ceiling.

When designing a system that must maintain stability over weeks of uptime without a garbage collector, the trade-off between the flexibility of the GPA and the predictability of a FixedBuffer or Arena approach is unclear.

• Does the ArenaAllocator introduce significant fragmentation if used repeatedly within a loop for request-scoped data?
• What is the recommended pattern for transitioning from a GPA in development to a more performant, fragmentation-resistant allocator in production?