Улучшение производительности IXamlMetadataProvider

Question

При сборке релиза UWP toolchain создает класс, как вы видите ниже. Смысл производительности цикла очевиден, особенно если учесть, что он затем перебирает OtherProviders, которые (предположительно) имеют свои собственные массивы. Результат первого поиска по LookupTypeIndexByName кешируется в словаре , но эти циклы в массиве составляют значительную часть запуска приложения под профилировщиком.

Кто-нибудь имеет представление оКак настроить сборку для сокращения времени выполнения?

namespace App1.App1_XamlTypeInfo
{
    internal partial class XamlTypeInfoProvider
    {
        private void InitTypeTables()
        {
            _typeNameTable = new string[444];
            _typeNameTable[0] = "Windows.UI.Xaml.ResourceDictionary";
            _typeNameTable[1] = "Object";
            _typeNameTable[2] = "Microsoft.UI.Xaml.Controls.XamlControlsResources";
            //...

            _typeTable = new global::System.Type[444];
            _typeTable[0] = typeof(global::Windows.UI.Xaml.ResourceDictionary);
            _typeTable[1] = typeof(global::System.Object);
            _typeTable[2] = typeof(global::Microsoft.UI.Xaml.Controls.XamlControlsResources);
            //...
        }

        private int LookupTypeIndexByName(string typeName)
        {
            if (_typeNameTable == null)
            {
                InitTypeTables();
            }
            for (int i=0; i<_typeNameTable.Length; i++)
            {
                if(0 == string.CompareOrdinal(_typeNameTable[i], typeName))
                {
                    return i;
                }
            }
            return -1;
        }

        //There's an implementation here, but this is just to illustrate it exists
        private List<IXamlMetadataProvider> OtherProviders { get; }
        private IXamlType CheckOtherMetadataProvidersForName(string typeName) { /*...*/ }
    }
}

---

EDIT

1. Сгенерированные классы не имеют необходимых модификаторов partial для изменения сгенерированныхclass.
2. Добавление явной реализации к App приводит к сбою всего процесса создания XamlTypeInfo.g.cs.
3. Из журнала сборки выглядит, как XamlTypeInfo.g.cs генерируется цельюMarkupCompilePass1. Я рассматриваю свою задачу по сборке, чтобы запустить Roslyn для изменения класса, хотя было бы неплохо, если бы он мог обрабатывать и OtherProviders.