improved score openning speed by optimisation the searchTemplateForInstrNameList function

[handrok]

It depends on the score and your machine. In my case, 10% of the time spent opening the score occurs inside the searchTemplateForInstrNameList function. The bottleneck here is the creation of StaffName(instrName) for each iteration of the loop, because the StaffName constructor calls TextBase::validateText, which performs a lot of work. Simply changing the order of three loops gave me a 10% boost in score opening time, as I tested.

[shoogle]

This might help too by avoiding copying strings unnecessarily:

for (const String& name : nameList) {
    if (name.isEmpty()) {
        continue;
    }

    const String& normalizedName = caseSensitive ? name : name.toLower();
    StaffName instrName(normalizedName);

[shoogle]

Avoiding another string copy:

const String& trackName = caseSensitive ? it->trackName : it->trackName.toLower();

[handrok]

String trackName = it->trackName;
muse::String is designed like QString from QT. It has move semantic. Copy of muse::String object doesn't lead to allocate memory. Only just pointer to shared memory is copied. Allocating memory is happening only if muse::String data is changed.

const String& trackName = it->trackName.toLower(); that code doesn't improve performance. memory is allocated inside of toLower() method. And toLower() creates local variable and return it. So memory was allocated anyway and one copy of muse::String object is happened. But as I said copying of muse::String is not a big problem. It has move semantic and copying muse::String is not much bigger then using of reference. sizeof(muse::String) is 16 bytes which is double of sizeof of reference. I think it is not a big deal. Instead of copy 8 bytes I copy 16 bytes here. And increase pointer count inside muse::String

[handrok]

But I cant change it if you insist.

[shoogle]

No, I'm happy with it. Thanks for the explanation!