Как повысить производительность с помощью TIBCO RV из C#?

Я использую TIBCO RV .NET API (TIBCO.Rendezvous.dll).

Знаете ли вы, есть ли лучший способ с точки зрения производительности для получения и чтения сообщений из канала RV в C#? Я обнаружил, что тип Message — логическая оболочка над сообщением RV — довольно тяжелый. Получение поля по имени или индексу может быть довольно медленным, особенно если рассматривать это как повторяющуюся/часто повторяющуюся операцию.

Любые идеи?


.net c# optimization tibco tibco-rv
person Romain Verdier    schedule 08.01.2009    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Основная проблема с оболочкой С# заключается в том, что она:

  • Выделяет для любого доступа к полю (API c/C++ предоставляет строго типизированные быстрые методы доступа для наиболее вероятных примитивов
  • помечает ссылки при каждом доступе к полю (вам не нужно делать это, если вы не планируете впоследствии обновлять поля и хотите избежать утечки памяти)
  • поиск полей по имени требует преобразования строки в строку ascii в стиле c

Эти аспекты затмят накладные расходы на базовые поиски на основе полей/имен, которых можно избежать, если вы знаете, что вам нужно просмотреть каждое поле в сообщении, перебирая поля по порядку. Это быстро в C/C++, поскольку он работает линейно через память и, таким образом, удобен для кэширования.

Лично мы обернули C++ api напрямую в C++ CLI (в то время библиотека .net была некачественной). Это сложно сделать правильно (особенно если у вас есть несколько доменов приложений), но он дает почти такую ​​же производительность, как API C++ (который является невероятно тонкой оболочкой API C).

Если ваше профилирование говорит вам, что выделения в рамках доступа к сообщениям не позволяют вашему приложению работать с нужной/желаемой скоростью, я боюсь, что у вас возникнут проблемы с библиотекой .net. Вы можете использовать отражение, чтобы получить базовый IntPtr для собственного сообщения, а затем использовать те же самые внешние функции в MessageToolbaox (внутренний класс в dll), которые выпадают на собственный API, стоимость доступа к внутреннему полю один раз за сообщение может быть компенсировано более быстрым поиском поля. Это, очевидно, хрупко и сложно поддерживать, но если вы обнаружите, что оно того стоит по сравнению с полной повторной реализацией их оболочки, это может помочь.

person ShuggyCoUk    schedule 24.02.2009

arrow_upward
1
arrow_downward

Я видел то же самое. По моему опыту, доступ к полям в сообщениях C# Rv очень медленный по сравнению с доступом к ним в C++. Таким образом, вы хотите избежать добавления и чтения нескольких полей в сообщение и из него.

Одно из решений — не использовать собственную сериализацию сообщений Rv. То есть не добавляйте много полей с помощью Message.AddField() и не получайте их с помощью Message.GetField(). Вместо этого вы можете сериализовать свои данные в непрозрачный тип (который представляет собой двоичный буфер, то есть массив байтов). Затем вы можете добавить это единственное поле в сообщение.

Если все, что вы делаете, это читаете и записываете одно поле, накладных расходов очень мало. И вы должны иметь возможность довольно быстро сериализовать и десериализовать данные в своем собственном коде.

person Richard Shepherd    schedule 19.12.2011