Closed Try closed 1 year ago
Hm, that would mean that you should have observed slower load times everywhere, especially when loading the VOb tree. There might be optimisations that can be done in messages
though.
I've made a few experiment locally:
removing std::stringstream
- generally nice, but not critical improvement.
replacing messages::_m_blocks_by_name
to sort + binary search - work quite well
// messages messages::parse(buffer& buf)
...
std::sort(msgs.blocks.begin(), msgs.blocks.end(), [](const message_block& l, const message_block& r){
return l.name<r.name;
});
return msgs;
}
const message_block messages::block_by_name(std::string_view name) const { auto it = std::lower_bound(blocks.begin(), blocks.end(), name, [](const message_block& l, std::string_view name) { return l.name < name; }); if (it!=blocks.end()) return ⁢ return nullptr; }
It certainly makes sense that not allocating potentially thousands of small std::string
s would make loading faster. Are you sure that in-game performance is actually acceptable using binary search instead of std::unordered_map
's O(1) access times?
Yes, I've tested this solution locally.
Also fetching block_by_name
relatively rare case (roughly a 1 call per 3 seconds). Worst what can happen is spike at search call.
Implemented :)
GameScript::loadDialogOU()
become noticeably slower with phenix backend.I haven't done proper profiling, but issue seem to be rooted in large amount of small allocations, while population hash-map. Lazy profiling(debug break a few times) shows, that this place can be an issue: