Имеется приложение, написанное на C++. Это сервис. С++, конечно, unmanaged.
Принимает запросы по некоторому сетевому интерфейсу, отдает ответы.
Часть с взаимодействием с другими сервисами, всякие gRPC и Кафки, пока не сделаны.
Часть для обработки запросов, сделана. Обработка сложная, на обработку одного запроса требуется 1-3 Гб памяти, и до нескольких секунд времени.
У сервиса есть свой кеш в памяти, примерно 50 Гб размером.
Есть мысль — не пытаться написать все на C++, а задействовать существующий код для взаимодействия с другими сервисами на C#
Переделать сервис в библиотеку, подключить ее в C# сервисе. Все внешнее взаимодействие будем писать на C#, там скорость не слишком важна. А часть где требуется производительность, которая к тому же уже сделана — оставляем на C++.

Насколько это хорошая идея, какие возможны проблемы?

Здравствуйте, andsm, Вы писали:

A>Насколько это хорошая идея, какие возможны проблемы?
Сейчас всё имеется на C++ и вопрос стоит ли переписывать на C# или я не понимаю проблемы ?

Здравствуйте, andsm, Вы писали:

A>Насколько это хорошая идея, какие возможны проблемы?

Главные вопросы — на стыке managed/unmanaged. Кто и по какому сценарию контролирует время жизни manged-объектов, насколько велики unmanaged порции данных, можно ли обойтись без копирования данных между этими рантаймами и т.п.

А так — технически всё возможно. Либо через PInvoke, либо через С++ CLI/CX

Здравствуйте, _NN_, Вы писали:

_NN>Сейчас всё имеется на C++ и вопрос стоит ли переписывать на C# или я не понимаю проблемы ?

Нет, сейчас написана на C++ только часть с собственно обработкой запроса. Все остальное еще не сделано.
Например, не сделан gRPC, взаимодействие с Кафкой и еще ряд инфраструктурных элементов. Причем, в C# все это уже есть, только чуть подправить.
Делать же все это на C++ означает, что потратим кучу дополнительного времени.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Главные вопросы — на стыке managed/unmanaged. Кто и по какому сценарию контролирует время жизни manged-объектов, насколько велики unmanaged порции данных, можно ли обойтись без копирования данных между этими рантаймами и т.п.

MD>А так — технически всё возможно. Либо через PInvoke, либо через С++ CLI/CX

То, что это технически возможно, это-то понятно.
Тут хочется понять, какие потенциально могут быть проблемы.
Unmanaged часть данных — это примерно 50 Гб.
Managed часть, если ее делать принимает запросы по gRPC, вызывает Unmanaged c полученными параметрами, отдает ответ.
Получает сообщения от Кафки, передает в unmanaged.
Запрашивает снапшоты данных на старте, у других сервисов, отдает в unmanaged. Ну и еще тут же всякие метрики и Prometheus.
Т.е. managed объекты долго не живут, объемы незначительны.

Здравствуйте, andsm, Вы писали:

A>Здравствуйте, _NN_, Вы писали:

_NN>>Сейчас всё имеется на C++ и вопрос стоит ли переписывать на C# или я не понимаю проблемы ?

A>Нет, сейчас написана на C++ только часть с собственно обработкой запроса. Все остальное еще не сделано.
A>Например, не сделан gRPC, взаимодействие с Кафкой и еще ряд инфраструктурных элементов. Причем, в C# все это уже есть, только чуть подправить.
A>Делать же все это на C++ означает, что потратим кучу дополнительного времени.

Если уже есть готовая работа на C#, звучит так, что переписывать на C++ добавит ещё работы.
Быстродействие текущее устраивает ? Если нет, то стоит посмотреть узкие места.
А там будет понятно стоит ли игра свеч.
Вполне возможно использование небезопасного (unsafe) кода или Span, может решить проблему быстрее чем переписывать на плюсы.

Здравствуйте, andsm, Вы писали:

A>То, что это технически возможно, это-то понятно.
A>Тут хочется понять, какие потенциально могут быть проблемы.
A>Unmanaged часть данных — это примерно 50 Гб.
A>Managed часть, если ее делать принимает запросы по gRPC, вызывает Unmanaged c полученными параметрами, отдает ответ.
A>Получает сообщения от Кафки, передает в unmanaged.
A>Запрашивает снапшоты данных на старте, у других сервисов, отдает в unmanaged. Ну и еще тут же всякие метрики и Prometheus.
A>Т.е. managed объекты долго не живут, объемы незначительны.

Тогда в целом всё выглядит очень ОК. Главное чтобы все эти гигабайты лились сразу в unmanaged-память, и из неё же прямиком брались при отправке в gRPC.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, andsm, Вы писали:

A>>То, что это технически возможно, это-то понятно.
A>>Тут хочется понять, какие потенциально могут быть проблемы.
A>>Unmanaged часть данных — это примерно 50 Гб.
A>>Managed часть, если ее делать принимает запросы по gRPC, вызывает Unmanaged c полученными параметрами, отдает ответ.
A>>Получает сообщения от Кафки, передает в unmanaged.
A>>Запрашивает снапшоты данных на старте, у других сервисов, отдает в unmanaged. Ну и еще тут же всякие метрики и Prometheus.
A>>Т.е. managed объекты долго не живут, объемы незначительны.

MD>Тогда в целом всё выглядит очень ОК. Главное чтобы все эти гигабайты лились сразу в unmanaged-память, и из неё же прямиком брались при отправке в gRPC.
Тут не всё так просто.
Передать массив туда обратно без лишней копии это просто:

byte myarray = new byte[1024*1024];
fixed (byte* ptr = myarray)
{
  CallCpp(ptr);
}

Это подходящий вариант ?

Здравствуйте, andsm, Вы писали:

A>Насколько это хорошая идея, какие возможны проблемы?

Посмотрите на трудоёмкость организации интерфейса на простом Си, т.е. extern C и простые методы, которые возвращают BLOB'ы. Если это просто, то и делайте. Если хочется отказоустойчивости, то можно организовать дочерние процессы от C# к C# с С++ внутри, общаться через stdin/stdout

Здравствуйте, andsm, Вы писали:

A>Насколько это хорошая идея, какие возможны проблемы?

Если С++ дает нужные преимущества по скорости, то решение норм.

Что может пойти не так — взаимодействие с unmanaged. Т.е. нужно корректно описать PInvoke, чтобы правильно call stack очищался, например. Плюс аллоцировать освобождать память должен один "собственник" — если выделить память в библиотеке, то там же и освобождать. Иначе могут быть спецэффекты (какие точно не скажу, но судя по сообщениям этого форума — они точно будут)