Можно ли получить собственную производительность для динамически скомпилированного кода, который можно выгружать?
У меня есть функция, которая использует древовидную структуру словарей для сопоставления с входящими структурами, поступающими со скоростью несколько 100k/ сек.
Это уже довольно быстро, но это должно стать еще быстрее. Чтобы измерить, насколько быстрее это будет получено, скомпилировав этот кусок кода наиболее производительным способом, я жестко запрограммировал оптимизированную функцию для определенного дерева словарей, используя вложенные операторы switch (в этом случае переключение bytes), и сравнил это с версией словарного стиля. Как вы могли догадаться, улучшения производительности были колоссальными: жестко запрограммированная версия коммутатора требует всего 20% процессорного времени динамической версии словаря.
Поскольку дерево создается динамически во время выполнения и время от времени изменяется, я подумал, что я мог бы просто динамически CompileAssemblyFromSource преобразовывать дерево в версию оператора switch во время выполнения каждый раз, когда оно изменяется, и я полагаю, что получу ту же производительность, что и мой жесткий -кодированная версия дала мне - за исключением, возможно, дополнительных затрат на необходимость вызова виртуального метода вместо статического вызова функции, который я могу выполнять при вызове жестко-закодированной функции.
Проблема в том, что сгенерированный таким образом код не может быть выгружен из памяти и, следовательно, будет течь со временем, если я не создам код в его собственном домене приложений, что позволяет мне выгружать его, выгружая весь домен приложений.
В этом и заключается подвох: связь между доменами приложений обходится дороже, чем внутри одного домена приложений. И я полагаю, что чрезмерные издержки (более чем?) Уничтожат выгоды операторов switch.
Так есть ли способ получить собственную производительность для динамически меняющейся проблемы, подобной этой, без утечки памяти?
Или в.net нет способа быть динамически адаптивным и статически быстрым? (Конечно, для того, чтобы это имело смысл, обязательно, чтобы количество вызовов значительно превышало динамизм рассматриваемого кода.)
NB. Меня не беспокоит время для компиляции структуры - это может занять столько времени, сколько потребуется.