Dialogs parsing performance

[Try]

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:

    bool archive_reader_binsafe::read_object_begin(archive_object& obj) {
        ...
        std::stringstream ss {line.substr(1, line.size() - 2)}; // substr creates a copy; and well stringstream known to be slow
        ss >> obj.object_name >> obj.class_name >> obj.version >> obj.index;
        return true;
    }

[lmichaelis]

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.

[Try]

I've made a few experiment locally:

1. removing std::stringstream - generally nice, but not critical improvement.

2. 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 &it; return nullptr; }

[lmichaelis]

It certainly makes sense that not allocating potentially thousands of small std::strings 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?

[Try]

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.

[lmichaelis]

Implemented :)