Вы смотрите в совершенно неправильных местах. «Затраты» на архитектуру документа / представления находятся в наносекундном диапазоне (в основном, доступ к данным через указатель).
Для сравнения, абсолютная максимальная частота, с которой вы можете существенно обновить экран, представляет собой частоту обновления монитора, которая обычно составляет 60 Гц (то есть один раз каждые 16,67 миллисекунды).
Чтобы сделать даже такую частоту обновления значимой, вы не можете сильно изменить ни одно обновление монитора - если вы попытаетесь изменить слишком много, пользователь не сможет следить за происходящим.
Что касается многопоточности, то на сегодняшний день самый простой способ - это выполнить все фактические обновления окна в одном потоке и использовать другие потоки для выполнения вычислений и т. Д., Которые генерируют данные для обновляемого окна. Если вы уверены, что потоку не нужно выполнять много вычислений и т. Д., Обновление окна настолько быстро, насколько это возможно, довольно просто.
Edit: насколько C ++ против C #, это зависит. Я не сомневаюсь, что вы можете получить абсолютно адекватную дисплей производительность от любого из них. Реальный вопрос в том, сколько вычислений вы делаете за этими дисплеями. То, что вы упомянули, отображало в основном довольно близко к необработанным данным (цена, объем и т. Д.). Для этого C #, вероятно, подойдет. Я полагаю, что люди, с которыми вы общались, делают гораздо больше вычислений, чем это - и это настоящее исцеление Ахиллеса от .NET (или почти всего, что работает на ВМ). Из того, что я видел, для очень тяжелых вычислений C # и тому подобное не очень конкурентоспособны.
Например, в другом ответе я упомянул приложение, которое я изначально написал на C ++, которое другая команда переписала на C #, которое работало примерно в 3 раза медленнее. С тех пор, как я это опубликовал, мне было любопытно, и я немного поговорил с ними об этом, спрашивая, не могут ли они улучшить его скорость, чтобы быть по крайней мере близкими к C ++ с небольшой дополнительной работой.
Их ответ был, по сути, тем, что они уже проделали эту дополнительную работу, и это было не просто "немного". Переписывание C # заняло примерно 3 1 / 2-4 месяца. Из этого времени им потребовалось менее месяца, чтобы продублировать функции оригинала; все остальное время было потрачено (чтобы) сделать его достаточно быстрым, чтобы его можно было использовать.
Спешу предупредить, что 1) это только одна точка данных, и 2) я понятия не имею, насколько это близко к тому, что вы могли бы сделать. Тем не менее, он дает некоторое представление о замедлении, с которым вы можете столкнуться, когда (и если) вы начнете делать реальные вычисления, а не просто передавать данные из сети на экран. В то же время, быстрый взгляд показывает, что в целом он соответствует результатам на веб-сайте Computer Language Shootout - хотя имейте в виду, что результаты есть для Mono, а не для реализации Microsoft.
По крайней мере для меня реальный вопрос сводится к следующему: действительно ли ваша забота о производительности действительно обоснована или нет? Для примерно 90% приложений важно то, что код делает того, что вам нужно, 1026 *, и скорость выполнения не имеет большого значения, пока он не получает радикально * На 1028 * медленнее (например, в сотни или тысячи раз медленнее). Если ваш код попадает в эту (большую) категорию, C # вполне может быть хорошим выбором. Если у вас действительно есть веская причина для беспокойства по поводу скорости исполнения, то мне кажется, что выбор C # будет лотом более сомнительным.