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

Remade who list processing #18636

Merged
merged 4 commits into from Jan 29, 2017
Merged

Remade who list processing #18636

merged 4 commits into from Jan 29, 2017

Conversation

ghost
Copy link

@ghost ghost commented Dec 27, 2016

Target branch(es): 3.3.5

  • 3.3.5

Issues addressed: References #14274

Tests performed: Compiles and basic ingame tests

Requests are now processed in maps. Player entries are now copied every 5 seconds to dedicated storage (avoids usage of hashmapholder mutex)

Improvements: Move processing to separate thread

…r entries are now copied every 5 seconds to dedicated storage (avoids usage of hashmapholder mutex)
_whoListStorage.clear();
_whoListStorage.reserve(sWorld->GetPlayerCount()+1);

boost::shared_lock<boost::shared_mutex> lock(*HashMapHolder<Player>::GetLock());
Copy link
Member

Choose a reason for hiding this comment

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

I've been thinking a bit about this, is this lock even needed for player storage? entries are only added/removed from the main thread (and you are looping this in main thread as well)

Copy link
Author

Choose a reason for hiding this comment

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

True, it's unneeded because this is done in main loop and even if other thread could run parallel to this it should not modify the player storage (except for reading)


std::string aname;
if (AreaTableEntry const* areaEntry = sAreaTableStore.LookupEntry(itr->second->GetZoneId()))
aname = areaEntry->area_name[sWorld->GetDefaultDbcLocale()];
Copy link
Member

Choose a reason for hiding this comment

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

you must not store the area name, this will break lookups in other locales

Copy link
Author

Choose a reason for hiding this comment

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

Is caching names for all locales ok?

Copy link
Contributor

@Rochet2 Rochet2 Dec 27, 2016

Choose a reason for hiding this comment

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

Do you really need to cache the name at all? Just cache the zone/area ID.
Getting the name is already just 2 array lookups which are constant and lockless. (not even a hashmap lookup). Caching probably gives little to no benefit. Or then I just dont see something here.

I guess the real speedup/benefit in this change was from trying to eliminate Player needed in the who list call, but area name is not something that needs player at all, is it?

Copy link
Author

Choose a reason for hiding this comment

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

Right, already done that

uint32 GetZoneId() const { return _zoneid; }
uint8 GetGender() const { return _gender; }
bool IsVisible() const { return _visible; }
std::wstring const& Getwpname() const { return _wpname; }
Copy link
Member

Choose a reason for hiding this comment

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

these names are horrible...

if (AreaTableEntry const* areaEntry = sAreaTableStore.LookupEntry(itr->second->GetZoneId()))
aname = areaEntry->area_name[sWorld->GetDefaultDbcLocale()];

_whoListStorage.push_back( WhoListPlayerInfo(itr->second->GetGUID().GetCounter(), itr->second->GetTeam(), itr->second->GetSession()->GetSecurity(), itr->second->getLevel(),
Copy link
Member

Choose a reason for hiding this comment

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

and since we are actually using c++11 features you could just .emplace_back(arg list) it

@Shauren
Copy link
Member

Shauren commented Dec 27, 2016

Whats up with the lowguid love? Always prefer full guid unless you are saving it to database (also a bit wishful thinking: if cross-realm lfg/bg ever happens then you need full guid as it will contain realm identifier part)

@ghost
Copy link
Author

ghost commented Dec 27, 2016

A habit of mine

{
Player* target = itr->second;
WhoListPlayerInfo target = *itr;
Copy link
Contributor

Choose a reason for hiding this comment

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

const& this :P

Copy link
Author

Choose a reason for hiding this comment

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

Done

@ghost ghost added the Sub-Miscellaneous label Jan 28, 2017
@ariel- ariel- merged commit 88f7469 into TrinityCore:3.3.5 Jan 29, 2017
Shauren pushed a commit that referenced this pull request Jul 21, 2019
* Remade who list processing, requests are now processed in maps. Player entries are now copied every 5 seconds to dedicated storage (avoids usage of hashmapholder mutex)

(cherrypicked from 88f7469)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants