Jump to content
  • Advertisement
Sign in to follow this  
Solid_Spy

Would multiple std::vectors be too slow?

This topic is 2119 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I'm trying to make a game using an std::vector<smart_Ptr<game_Objec>> for my game object list.

 

However, I also have plans to make multiple weak_Ptr lists for references of certain objects, for example:

 

a list only for objects that need to be rendered, a list for objects that can collide with each other, etc...

 

I would have to flush out and update these lists every frame, which could result in 1000's of allocations and deallocations each frame, and I know that that would be slow, but would it be too slow?

 

should I just use the main list and check if each object is renderable or collide instead? whatever method would be faster Is what I'm deciding on. What method would be better?

Edited by Solid_Spy

Share this post


Link to post
Share on other sites
Advertisement

Maybe you can sort them into a few different vectors for the possibly few exact object types to avoid having to use vectors of shared_ptr to the baseclass. That would also avoid having to test each object for its type or creating those other vectors containing weak_ptr, when you for example know only 2 types of objects and therefore 2 of the vectors need to be tested for collision.

Edited by wintertime

Share this post


Link to post
Share on other sites

It is extremely unlikely to be a problem.

 

You need to think about macro rather than micro. Use the simplest scheme that you think might work.

 

The key is to avoid anything which is greater than O(N) on a regular basis (e.g. each frame). Even the N^2 "every object against every other object" is not really so bad provided the number of objects doesn't get too big.

 

It's really possible to iterate a lot of vectors - really, lots - each frame, without problems.

Share this post


Link to post
Share on other sites

std::vector’s do not free their memory when you clear them.  Just make sure the vectors themselves are not created and destroyed repeatedly.

 

 

L. Spiro

Share this post


Link to post
Share on other sites

std::vector’s do not free their memory when you clear them.  Just make sure the vectors themselves are not created and destroyed repeatedly.

 

 

L. Spiro

I understand the vector itself doesn't get it's memory freed, i mean the objects stored in the vector. If I'm adding and removing thousands of objects per frame, isn't that supposed to be extremely slow? I've tried testing for framerates, but I haven't gotten that down yet.

Share this post


Link to post
Share on other sites

It obviously would be, which is why you don’t store objects in the vectors, you store pointers to objects.

 

 

L. Spiro

Share this post


Link to post
Share on other sites

It obviously would be, which is why you don’t store objects in the vectors, you store pointers to objects.

 

 

L. Spiro

Well isn't creating and destroying pointers thousands of times a frame also very slow?

Share this post


Link to post
Share on other sites

If you don't clear your vector of smart_Ptrs, it might be fine. But a good amount of this depends on your implementation of smart_Ptr and weak_Ptr. If they're like the std:: versions, then they might have extra overhead associated with them that might not be acceptable for you situation and your target platform.

 

But of course, if you have CPU cycles to spare in your game, then it won't make a difference. I guess it depends on how CPU intensive you plan on your game being.

Share this post


Link to post
Share on other sites

 

It obviously would be, which is why you don’t store objects in the vectors, you store pointers to objects.

 

 

L. Spiro

Well isn't creating and destroying pointers thousands of times a frame also very slow?

 

Not really.

 

There's two points to what you're saying really, one is that creating and destroying a lot of something in a short period of time is slow, well, slow is relative. Usually creating and destroying thousands of objects every frame is a bad idea but pointers are very small and simplistic and creating them doesn't take much time, objects are expensive because if its a game object that usually implies a thousand constructors to call, memory to allocate and free, possibly quite a lot of memory depending on how fancy the objects are.

 

Essentially a pointer compared to most game objects is like a box of donuts vs a shipping container full of cars.

 

The second point is you're asking if this is a /bad/ thing really. In a way it sort of is, there are probably better alternatives to just clearing and creating and sorting a large number of objects usually but in my experience usually the more efficient or generic code becomes the longer it takes to write. Generally thats why people recommend having the mindset of "If you can make it work in a simple way, do it, refactor later." Besides, if performance becomes a problem then you'll have to stop and evaluate -why- it is slowing the game down and ways you can go about fixing it.

 

There's no silver bullet, everything has tradeoffs. If it didn't we'd all just use one giant game engine that did everything perfectly.

Share this post


Link to post
Share on other sites

If your object are all owned by the game object list and the other lists are reconstructed each frame, why do you need smart pointers and weak pointers, instead of, say, scoped pointers and indices?

 

You could also design your game objects to use intrusive smart pointers (reference count is part of the game object) instead of requiring allocations for the standard smart pointers.

 

Anyway, you shouldn't decide on what's faster by posting to a forum. You should decide by writing up both implementations and measuring it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!