Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize IOLoginData::saveItems by reducing number of allocations #3176

Merged
merged 2 commits into from
Sep 17, 2021
Merged

Optimize IOLoginData::saveItems by reducing number of allocations #3176

merged 2 commits into from
Sep 17, 2021

Conversation

marksamman
Copy link
Member

Note that this is untested, just an idea I got by quickly looking at the function. std::list would allocate for each push, std::vector tends to have a growth strategy where it only allocates when it reaches capacity

@nekiro
Copy link
Member

nekiro commented Oct 24, 2020

This is interesting. I saw a lot of places in source where we use std::list or pop_front, if I understand correctly if you pop_front, all items in list have to be relocated to index - 1, which does not sound like a good performance thing, so this code should be faster right?

Why reserving only 32 though?

@marksamman
Copy link
Member Author

marksamman commented Oct 24, 2020 via email

@ranisalt
Copy link
Member

ranisalt commented Jan 28, 2021

I think the biggest gains are moving to a container with contiguous allocation, it's just faster to access. The STL implementation of vector doubles in size when it hits the capacity, so it only avoids 5 small reallocations at best.

Another good point is that a list is just wastes a lot of memory with pointers.

This might be the perfect use case of a std::deque, which is a compromise between a list and a vector. Or even a stack, if ordering is not important.

if I understand correctly if you pop_front, all items in list have to be relocated to index - 1

Wrong, a std::list is a linked list and insertions in any position are constant (provided that you have the iterator, and you always have for front and back).

Copy link
Member

@DSpeichert DSpeichert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this started an avalanche of converting things to use vectors, so we should probably revisit this. LGTM, since there are no better proposals.

@DSpeichert DSpeichert merged commit a6ad4d6 into otland:master Sep 17, 2021
@Zbizu Zbizu mentioned this pull request Oct 17, 2021
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants