swarm_pool
An object pooling system for Rust, optimized for perfomance.
Contents
- version 0.1.8:
- Added
kill_all()methode toSwarm. Kill all removes all spawns at once, can only be called from Swarm itself, NOT from SwarmControl. - Added Benchmark and ECS documentation to this README.
- Added
- version 0.1.7:
- Removed
Copydependencies, PoolObjects do no longer rely on the implementation of theCopytrait. - Implemented the
Clone&Defaulttraits forSpawn. Spawn.clone() behaves in the same way as Spawn.mirror() does. The These where implemented so that PoolObjects can hold Spawn reference objects as field properties. Default on Spawn should not be used and is only there to make the above possible.
- Removed
- version 0.1.4:
- Added iterators
find(),for_while(),for_each(),for_all()&enumerate()toSwarmComtrol, these makes it possible to iterate over all spawns inside the update() loop.
- Added iterators
The pooling system manages object instances of a cutom type, and provides update loops to iterate over them.
In order to create a new swarm pool, you need to define what your pool object and swarm properties types
are going to look like. Your pool object must at leas implement the Default, Copy and Clone traits
from the standard library. The swarm properties, on the other hand, does not depend on any traits.
Basic swarm setup example
extern crate swarm_pool;
use Swarm;
// create an object you want to pool
// create properties you want to share with pooled objects
;
The swarm is now ready to be used. First of all we need to Spawn new pool instances. In reality all objects in the pool are allready created and are waiting to be used. This means that all objects ( from 0 up to, but not including, the maximum capacity) can be accessed through the fetch() methode. The difference between spawned and non-spawned pool objects is that spawned object are included in all of the Swarm pools iterator methodes and non-spawned object are not.
Spawning and looping
let mut swarm = new;
let spawn1 = swarm.spawn.unwrap;
let spawn2 = swarm.spawn.unwrap;
assert_eq!;
assert_eq!;
swarm.for_each;
assert_eq!;
assert_eq!;
The real power of this library is not just looping through a few object instances, it is controlling and cross referencing them.
There are 2 powerful methodes that can be used to do so: Swarm.for_all() and Swarm.update().
Both have their advantages and disadvantages, for_all loop is fast (equal to a standard vec for loop) but cannot spawn nor kill
pool objects, update is easy to use, gives full control, but is slow (less than half the speed).
Cross referencing using for_all & update
// change properties to contain references to our spawned pool objects
let properties = MySwarmProperties ;
let mut swarm = new;
let s_john = swarm.spawn.unwrap;
let s_cristy = swarm.spawn.unwrap;
swarm.properties.john = Some;
swarm.properties.cristy = Some;
swarm.fetch.name = "John";
swarm.fetch.name = "Cristy";
// using the for_all methode
swarm.for_all;
assert_eq!;
assert_eq!;
// using the update methode
swarm.update;
assert_eq!;
assert_eq!;
There are many more functionalities included in the Swarm and SwarmControl types. The documentation on the examples above or other functionalities this library provides are more in depth and should be read, for writing them out was a lot of work ;)
Benchmark performance is tested using a standard Vector as baseline. This standard vector is populated by the same object type and a standard for loop is used to iterate over the elements. Every object, when called, adds one to its value property.
0.1.8 - Benchmark results on my i7 laptop:
1. Standard Vec bench for 1 object(s).. 814M calls/s @ 814M upd/s
2. Swarm.for_each() bench with 1 object(s).. 825M calls/s(101%) @ 825M upd/s
3. Swarm.for_all() bench with 1 object(s).. 677M calls/s(83%) @ 677M upd/s
4. Swarm.update() bench with 1 object(s).. 530M calls/s(65%) @ 530M upd/s
5. Standard Vec bench for 10 object(s).. 1568M calls/s @ 156.8M upd/s
6. Swarm.for_each() bench with 10 object(s).. 1596M calls/s(102%) @ 159.6M upd/s
7. Swarm.for_all() bench with 10 object(s).. 1049M calls/s(67%) @ 104.9M upd/s
8. Swarm.update() bench with 10 object(s).. 695M calls/s(44%) @ 69.5M upd/s
9. Standard Vec bench for 100 object(s).. 1550M calls/s @ 15.5M upd/s
10. Swarm.for_each() bench with 100 object(s).. 1419M calls/s(92%) @ 14.19M upd/s
11. Swarm.for_all() bench with 100 object(s).. 1051M calls/s(68%) @ 10.51M upd/s
12. Swarm.update() bench with 100 object(s).. 676M calls/s(44%) @ 6.76M upd/s
13. Standard Vec bench for 1000 object(s).. 1234M calls/s @ 1.234M upd/s
14. Swarm.for_each() bench with 1000 object(s).. 1231M calls/s(100%) @ 1.231M upd/s
15. Swarm.for_all() bench with 1000 object(s).. 1058M calls/s(86%) @ 1.058M upd/s
16. Swarm.update() bench with 1000 object(s).. 678M calls/s(55%) @ 0.678M upd/s
# RESULTS TOTAL
* Plain vec results:
- average of '1292M' calls/s
- lowest of '814M' calls/s (bench #1)
- highest of '1568M' calls/s (becnh #5)
* swarm.for_each() results:
- average of '1268M' calls/s
- average speed was '98.168%' of plain vector speed
- lowest of '825M' calls/s (becnh #2)
- highest of '1596M' calls/s (becnh #6)
* swarm.for_all() results:
- average of '959M' calls/s
- average speed was '74.242%' of plain vector speed
- lowest of '677M' calls/s (becnh #3)
- highest of '1058M' calls/s (becnh #15)
* swarm.update() results:
- average of '645M' calls/s
- average speed was '49.916%' of plain vector speed
- lowest of '530M' calls/s (becnh #4)
- highest of '695M' calls/s (becnh #8)
The result varies per test run, but the average speed percentage always seems somewhat stable. In other words, the benchmark results give a general idea what the scope of your ballpark is going to be when using the swarm_pool library.
For those whome would like to dive into ECS engine developement, the question: "Can one take a swarm_pool and turn it into an ECS engine?", the answer is: "Yes, one could".
I've tried different ways of using the Swarm pool to create an ECS engine. It turns out that, when using the swarm pool, the Option<> approach seems to be faster than the classic bitflag strategy. In other words, wrapping your Components in a standard Option, and perform a per object test if that object has Some(component) for the system that is looping through the swarm.
ECS Example
;
;
;
You might have noticed the use of for_all() instead of update(). Update is slower and therefore, when building your own engine, it is preferable to use for_all. I would advice to only use update if you need to kill/spawn during update or you need to loop through all objects while looping through all objects.