Универсальные интерфейсы в C# предотвращают упаковку? (.NET по сравнению с Моно производительностью)
Вы можете отслеживать HTTP-запросы к различным микросервисам (приложениям), используя специальный заголовок, чтобы сопоставить все последующие запросы с исходным.
Например, ваше веб-приложение отправляет HTTP-запрос (вызов API REST) первому микросервису (A), который обнаруживает, что у запроса нет идентификатора корреляции (заголовок x-correlationid), и добавляет его, а затем сохраняет эту корреляцию. id в текущий контекст вызова / сеанса и перенаправляет его на все последующие вызовы API другим микросервисам. затем, когда все другие микросервисы будут следовать той же логике, они также будут добавлять / использовать идентификатор корреляции, у вас будет возможность отслеживать запросы по всем микросервисам в системе.
этот шаблон используется многими инструментами APM (мониторинг производительности приложений). и после того, как все ваши журналы агрегированы в одном месте, вы можете отфильтровать ваши запросы по определенному идентификатору корреляции, чтобы увидеть полный след конкретного пользовательского запроса / операции.
6 ответов
Я не уверен, как это реализовано в моно, но универсальных интерфейсах, поможет, потому что компилятор создает новую функцию определенного типа для каждого используемого другого типа (внутренне, существует несколько случаев, где это может использовать ту же сгенерированную функцию). Если функция определенного типа сгенерирована, нет никакой потребности упаковать/распаковать тип.
Это то, почему Наборы. Универсальная библиотека имела шумный успех в.NET 2.0, потому что наборы больше не требовали упаковки и становились значительно более эффективными.
Проблема с MyClass2 состоит в том, что преобразование байта [] к и от объекта упаковывает и распаковывает, которые являются в вычислительном отношении дорогими операциями, влияющими на производительность.
Нет никакой упаковки, связанной с типами массива, даже один с элементами типа значения. Массив является ссылочным типом.
Издержки на (байт []) аргумент минимальны в лучшем случае
Вы извлечете ту же пользу в Моно, который Вы делаете в.NET.
Мы настоятельно рекомендуем использовать Моно 1.9 или Моно 2.0 RCx в целом, поскольку дженерики поддерживают только назревший с 1,9.
Я не могу говорить с Моно, но использование универсального интерфейса должно решить проблему упаковки/распаковывания во времени выполнения MS.
Да, в .NET (MS, не уверенный в моно), дженерики реализованы во время компиляции, таким образом, нет никакой упаковки или распаковывания продолжения вообще. Контраст по отношению к дженерикам Java, которые являются синтаксическим сахаром, которые просто выполняют броски для Вас в фоновом режиме (по крайней мере, это был этот путь однажды). Основная проблема с дженериками - Вы, не может рассматривать универсальные контейнеры полиморфно, но это немного от Вашей темы :-)
Учитывая Вы используете последнюю версию моно, 2.0, если Вы можете.
Универсальная интерфейсная производительность на Моно очень хороша на паре с регулярной интерфейсной отправкой.
Отправка универсальных виртуальных методов [1] ужасна на всех выпущенных версиях моно, она улучшилась в 1.9 тыс.
Проблема не состоит в том, что плохо, поскольку проблема производительности с универсальными виртуальными методами была устранена для следующего выпуска моно (2.2), который планируется в конец этого года.
[1] Универсальный виртуальный метод - что-то как:
открытый интерфейс Foo {
void Bla<T> (T a, T b);
}