Return to Answer

Note that this answer might be a bit overkill. I'm not really accounting for productivity at all and assuming you have a bit of extra time to deal with the inconvenience of storing everything in one big container and possibly implementing that indexed free list above (I'm not a good person to ask for efficient solutions that can be implemented in 10 minutes... well, I think I can implement these in 10 minutes but only because I've had lots of practice). That 500,000 agents thing above is not even close to the scale of the inputs I work with regularly (it's small in comparison). For VFX it's not uncommon to deal with hundreds of millions, and so I'm often required to use these types of techniques at the bare minimum just to get acceptable performance that won't have users complaining that some other software is faster or having studios switch to simulating with something else on their farms. But I get kinda excited to share some very general techniques to speed things up, and a good one that doesn't get too fancy and hopefully isn't too overkill is just index your elements and store everything in big containers, not a boatload of small ones.

Note that this answer might be a bit overkill. I'm not really accounting for productivity at all and assuming you have a bit of extra time to deal with the inconvenience of storing everything in one big container and possibly implementing that indexed free list above (I'm not a good person to ask for efficient solutions that can be implemented in 10 minutes... well, I think I can implement these in 10 minutes but only because I've had lots of practice). For VFX it's not uncommon to deal with hundreds of millions of particles, and so I'm often required to use these types of techniques and handroll containers at the bare minimum just to get acceptable performance that won't have users complaining that some other software is faster or having studios switch to simulating with something else on their farms. But I get kinda excited to share some very general techniques to speed things up, and a good one that doesn't get too fancy and hopefully isn't too overkill is just index your elements and store everything in big containers, not a boatload of small ones. I'm actually restraining myself a lot for this answer because there's a lot more I can cover on this topic including an alternative to that indexed free list for the largest scale inputs (far more complex to implement), but I'll stop here!

Note that this answer might be a bit overkill. I'm not really accounting for productivity at all and assuming you have a bit of extra time to deal with the inconvenience of storing everything in one big container and possibly implementing that indexed free list above. That 500,000 agents thing above is not even close to the scale of the inputs I work with regularly (it's small in comparison). For VFX it's not uncommon to deal with hundreds of millions, and so I'm often required to use these types of techniques at the bare minimum just to get acceptable performance that won't have users complaining that some other software is faster. But I get kinda excited to share some very general techniques to speed things up. But a good one that doesn't get too fancy is just index your elements and store everything in big containers, not a boatload of small ones.

Note that this answer might be a bit overkill. I'm not really accounting for productivity at all and assuming you have a bit of extra time to deal with the inconvenience of storing everything in one big container and possibly implementing that indexed free list above (I'm not a good person to ask for efficient solutions that can be implemented in 10 minutes... well, I think I can implement these in 10 minutes but only because I've had lots of practice). That 500,000 agents thing above is not even close to the scale of the inputs I work with regularly (it's small in comparison). For VFX it's not uncommon to deal with hundreds of millions, and so I'm often required to use these types of techniques at the bare minimum just to get acceptable performance that won't have users complaining that some other software is faster or having studios switch to simulating with something else on their farms. But I get kinda excited to share some very general techniques to speed things up, and a good one that doesn't get too fancy and hopefully isn't too overkill is just index your elements and store everything in big containers, not a boatload of small ones.

Now using something like boost::small_vector or llvm::SmallVector is a very good solution, far superior to requiring a heap allocation for every particle as would be the case if you used std::vector for each one. Chris' answer is already really good. But if you want to persistently store the contacts, these small buffer optimizations start to get a little bit explosive in memory use which can translate to extra cache misses (they are pretty great for temporary storage though), which is why I recommend just a big old vector of integers instead with the assumption that your simulation might be better off computing all the contacts at once rather than computing them on demand in getContacts (at which point a small vector would start to become much more appropriate).

Note that this answer might be a bit overkill. That 500,000 agents thing above is not even close to the scale of the inputs I work with regularly (it's small in comparison). For VFX it's not uncommon to deal with hundreds of millions. But I get kinda excited to share some very general techniques to speed things up. But a good one that doesn't get too fancy is just index your elements and store everything in big containers, not a boatload of small ones.

Now using something like boost::small_vector or llvm::SmallVector is a very good solution, far superior to requiring a heap allocation for every particle as would be the case if you used std::vector for each one. Chris' answer is already really good. But if you want to persistently store the contacts, these small buffer optimizations start to get a little bit explosive in memory use which can translate to extra cache misses (they are pretty great for short-lived storage though on the stack), which is why I recommend just a big old vector of integers instead with the assumption that your simulation might be better off computing all the contacts at once rather than computing them on demand in getContacts (at which point a small vector would start to become much more appropriate).

Note that this answer might be a bit overkill. I'm not really accounting for productivity at all and assuming you have a bit of extra time to deal with the inconvenience of storing everything in one big container and possibly implementing that indexed free list above. That 500,000 agents thing above is not even close to the scale of the inputs I work with regularly (it's small in comparison). For VFX it's not uncommon to deal with hundreds of millions, and so I'm often required to use these types of techniques at the bare minimum just to get acceptable performance that won't have users complaining that some other software is faster. But I get kinda excited to share some very general techniques to speed things up. But a good one that doesn't get too fancy is just index your elements and store everything in big containers, not a boatload of small ones.