Price history
Recorded standalone sale prices and the latest available store price, in USD. Historical dots use the sale start date and its recorded offer price. Prices can change during a sale; this is not a daily price log. Bundle prices and upcoming offers are excluded. History covers up to the 100 most recent recorded offers.
Lowest recorded standalone price in this history: $9.99. The latest store price is $9.99, matching the lowest recorded price shown here.
View 2 recorded prices
| Sale start / price check | Price | Observation |
|---|---|---|
| $9.99 | Latest store price | |
| $9.99 | Unity First Price 2026-09-04 2026-09-04 |
Sale and bundle history
The 1 most recent recorded offers including this asset. Past offers may no longer be available. Bundle prices cover a package, not this asset alone.
About Quick Object Pool Pro
Two lines. No manager object, no packages, nothing to add to a scene.
var bullet = Pool.Spawn(bulletPrefab, muzzle.position, muzzle.rotation);
Pool.Despawn(bullet);
Twenty thousand spawn-and-despawn pairs allocate 0 bytes. The same loop with Instantiate and Destroy allocates about 47 bytes a pair and hands the bill to the garbage collector, which pays it in one visible hitch some frames later. That number is measured, not claimed, and the demo scene puts it on screen while you watch.
NOTHING ALLOCATED ON THE HOT PATH
• No LINQ, no closures, no boxing, and no GetComponent
• Every component a pooled object needs is looked up once, when the object is built, and kept with it
• Per-object bookkeeping is a struct, so tracking an object costs nothing either
A WINDOW THAT TELLS YOU THE NUMBER
• Live hit rate, peak in use, and objects built
• "23 spawns have had to build an object mid-game. Prewarming 31 would have covered every one of them." — with a button that writes it into the profile
• Guessing pool sizes is the part nobody enjoys. This measures it from what your game actually did.
LEAK DETECTION WITH CALL SITES
• Objects that went out and never came back, how long they have been gone, and the line of code that spawned them
• A pool cannot reuse what nobody returns, so a leak shows up as a pool that only ever grows — and the cause is invisible
• This names it instead. Select the object straight from the list.
PREWARMING THAT DOES NOT HITCH
• Building a thousand objects in one frame is the very freeze pooling exists to prevent
• Prewarm is spread over frames against a millisecond budget
• The pool measures what a creation actually costs on the machine it is running on, so the budget means the same thing on a laptop and on a console
THE REST
• THREE WAYS TO RUN DRY — grow, recycle the oldest, or refuse and let the caller decide. Each explained in the inspector, including the trap: grow plus a ceiling behaves like refuse once it hits the ceiling.
• AUTO-RETURN — after a timeout, when a particle system finishes playing, or when an audio source stops. The two things people most often forget to return.
• IPooled — OnSpawned and OnDespawned for resetting state. A pooled object is not a new object; its fields hold whatever the last user left behind, and that is the single most common way pooling introduces bugs.
• THE AWKWARD CASES ARE HANDLED — despawning twice, despawning something that never came from a pool, an instance somebody else destroyed, a scene unload. None of them corrupt the free list, and the ones that are your bug say so.
• A DEMO SCENE IN THE PACKAGE — two guns firing the same prefab at the same rate, one pooled and one not, with managed memory growth and worst frame time on screen.
• PURE-C# POLICY — how much to prewarm this frame, what size to suggest, what counts as a leak. No Unity in it, so the inspector's numbers and the running game's numbers cannot disagree.
NO DEPENDENCIES
Not "no third-party dependencies" — no Unity packages either. Nothing to install, no TextMeshPro, no uGUI. It imports into a bare Built-in project with zero console errors, and works the same in URP and HDRP.
var bullet = Pool.Spawn(bulletPrefab, muzzle.position, muzzle.rotation);
Pool.Despawn(bullet);
Twenty thousand spawn-and-despawn pairs allocate 0 bytes. The same loop with Instantiate and Destroy allocates about 47 bytes a pair and hands the bill to the garbage collector, which pays it in one visible hitch some frames later. That number is measured, not claimed, and the demo scene puts it on screen while you watch.
NOTHING ALLOCATED ON THE HOT PATH
• No LINQ, no closures, no boxing, and no GetComponent
• Every component a pooled object needs is looked up once, when the object is built, and kept with it
• Per-object bookkeeping is a struct, so tracking an object costs nothing either
A WINDOW THAT TELLS YOU THE NUMBER
• Live hit rate, peak in use, and objects built
• "23 spawns have had to build an object mid-game. Prewarming 31 would have covered every one of them." — with a button that writes it into the profile
• Guessing pool sizes is the part nobody enjoys. This measures it from what your game actually did.
LEAK DETECTION WITH CALL SITES
• Objects that went out and never came back, how long they have been gone, and the line of code that spawned them
• A pool cannot reuse what nobody returns, so a leak shows up as a pool that only ever grows — and the cause is invisible
• This names it instead. Select the object straight from the list.
PREWARMING THAT DOES NOT HITCH
• Building a thousand objects in one frame is the very freeze pooling exists to prevent
• Prewarm is spread over frames against a millisecond budget
• The pool measures what a creation actually costs on the machine it is running on, so the budget means the same thing on a laptop and on a console
THE REST
• THREE WAYS TO RUN DRY — grow, recycle the oldest, or refuse and let the caller decide. Each explained in the inspector, including the trap: grow plus a ceiling behaves like refuse once it hits the ceiling.
• AUTO-RETURN — after a timeout, when a particle system finishes playing, or when an audio source stops. The two things people most often forget to return.
• IPooled — OnSpawned and OnDespawned for resetting state. A pooled object is not a new object; its fields hold whatever the last user left behind, and that is the single most common way pooling introduces bugs.
• THE AWKWARD CASES ARE HANDLED — despawning twice, despawning something that never came from a pool, an instance somebody else destroyed, a scene unload. None of them corrupt the free list, and the ones that are your bug say so.
• A DEMO SCENE IN THE PACKAGE — two guns firing the same prefab at the same rate, one pooled and one not, with managed memory growth and worst frame time on screen.
• PURE-C# POLICY — how much to prewarm this frame, what size to suggest, what counts as a leak. No Unity in it, so the inspector's numbers and the running game's numbers cannot disagree.
NO DEPENDENCIES
Not "no third-party dependencies" — no Unity packages either. Nothing to install, no TextMeshPro, no uGUI. It imports into a bare Built-in project with zero console errors, and works the same in URP and HDRP.