Небольшое сравнение производительности UWP/WinRT API языковых проекций

[maydjin]

Чтобы точнее измерить необходимое время на выполнение вычислений, приложения запускались без отладчика

А сборка то хоть релизная была?

[altk]

Конечно, тестировалась релизная сборка. Настройки компиляции релизной сборки не менял, значения были по-умолчанию (ну кроме того, что полностью выключил генерацию отладочной информации.

[crea7or]

Проверка границ массивов всё сожрала?

[altk]

Нет. В проектах, полагающихся на работу UWP/WinRT API никакие массивы в замере времени исполнения не участвуют.

[dordzhiev]

del

[g-man]

Что-то мне подсказывает, что большая часть времени уходит не на работу «в холостую» (и что это может значить в Вашем примере, если код все равно выполняется?), а на работу со строками.
В C# примере вы используете:
input = hasher.HashData(input);
input = Encoding.ASCII.GetBytes(CryptographicBuffer.EncodeToBase64String(input)).AsBuffer();

Здесь вы сначала хэшируете буфер, потом конвертируете в base64 string, затем в массив, а потом опять в буфер.

[altk]

Если вы посмотрите проекты CPPWRL или CPPCX, то сможете заметить, что там работает аналогичный код:

input = hasher->HashData(input);
String^ base64String;
base64String = CryptographicBuffer::EncodeToBase64String(input);
input = CryptographicBuffer::ConvertStringToBinary(base64String, BinaryStringEncoding::Utf8);

Для удобства восприятия могу его записать так:

input = hasher->HashData(input);
input = CryptographicBuffer::ConvertStringToBinary(CryptographicBuffer::EncodeToBase64String(input), BinaryStringEncoding::Utf8);

Кроме того. Привёл к этому же виду код проекта CSWinRT:

input = hasher.HashData(input);
input = CryptographicBuffer.ConvertStringToBinary(CryptographicBuffer.EncodeToBase64String(input), BinaryStringEncoding.Utf8);

Результаты стали даже хуже:

• C# Native — ~195000 миллисекунд
• C# — ~80000 миллисекунд

[g-man]

Так я не спорю, что это будет медленнее. Я говорю, что «в холостую» не совсем верное утверждение. Код не работает в холостую, он просто выполняется так, как Вы его написали — где-то быстрее, где-то медленнее.

[altk]

Спасибо за замечание. Внёс изменения в текст статьи.

[Alexx999]

Довелось мне очень плотно познакомиться с WinRT еще когда он только-только появился — а именно, поучаствовать в разработке Microsoft Minesweeper и других «стандартных» игр.
Могу подтвердить что работает оно невероятно медленно.
Причины — это урезанное (и очень медленное по сравнению с Win32) COM-based API плюс реализация .NET поверх этого API что убивает остатки производительности (да-да, рантайм .NET не имеет никаких «бонусов» в плане поддержки ОС).
Произошло так потому, что разработкой WinRT руководил дядька который ненавидел и стемился уничтожить .NET и сделал все что было в его силах чтобы .NET в WinRT работал настолько плохо, насколько это вообще возможно.
В итоге — приложения .NET работают в WinRT контейнерах заметно медленнее чем ожидается.

[melt]

А если не секрет, то чего хотел этот дядька? На чем, по его мнению, нужно разрабатывать для WinRT? Или он в целом хотел сделать платформу так себе?

[Diaskhan]

С++ жил, с++ жив, с++ будет жить,

www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=query
Здесь показывается Overhead веб фреймворков. Роза пахнет розой.

C#-Java это все таки абстракции, Иногда стоит пожертвовать скоростью в угоду удобства. Зато Абстракция дает вам дженерики словари, замыкания )))

[ForNeVeR]

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

[Diaskhan]

Managed Code ????

[ForNeVeR]

Managed code тоже есть в C++, но называть C++/CLI (или C++/CX) "стандартным" я бы не стал. В замечании выше речь идёт именно о варианте C++, описанном в соответствующих стандартах ISO.

[Diaskhan]

Много ли пишут Веб приложения и destop приложения на c++ в СНГ ?? Инструментом для быстрого создания проекта (EE) вряд ли можно назвать с++!

[ForNeVeR]

По моему опыту — да, достаточно много серверных компонентов веб-приложений, а также десктоп-приложений в СНГ разрабатываются с помощью C++. Хотя, честно говоря, я так и не понял, к какому заключению это рассуждение должно меня привести.

[Diaskhan]

Можете привести пример ?? Там где критична производительность там и оправдано использование с++.

[ForNeVeR]

К сожалению, меня связывает NDA, так что конкретные примеры привести не вправе. Могу только отметить, что это не публичные проекты, в которых, тем не менее, критично важна производительность в обработке большого количества поступающих запросов. И при этом на C++ пишутся не приложения целиком, а отдельные компоненты или сервера (которые могут общаться как по HTTP, так и по каким-то инхаузным протоколам по мере надобности).

Лично я бы тоже не стал называть C++ "инструментом для быстрого создания проекта" — так же, например, как и nodejs. Там, говорят, можно по несколько месяцев фреймворк выбирать ;)

Это я к тому, что тут всё-таки зависит от навыков программистов, а не от технологии. Видимо, надобности в массовом штамповании проектов на C++ в индустрии нет, поэтому соответствующего рода инструменты (типа какого-нибудь yeoman) не столь распространены.

[Diaskhan]

Это забавно, но я хотел сказать тоже самое!

Есть такая штука как https://lwan.ws/
А вот инфа насколько она быстра https://www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=json
Но это больше для маленького кода там где критична производительность. Писать же на нем Ентерпрайз решения, нееее, да нуу его. Забивать гвозди плоскогубцами, плохая затея.

Хотя конечно скорость загрузки потрясает…

[bondarenkod]

Если не ошибаюсь, вот тут про это написано как раз
Секция Keep your app fast when you use interop in managed code
Вот тут msdn.microsoft.com/en-us/windows/uwp/debug-test-perf/windows-runtime-components-and-optimizing-interop