Здравствуйте, vdimas, Вы писали:
V>Поиграй с распространением констант в С++.
Это вообще о чём?
Давайте пример кода, а то за вашим полётом мысли я не успеваю.

V>И да, что с чем ты собрался сравнивать?
V>Один запрос linq компиллируется от единиц до десятков ms.
V>Это не в синтетическом тесте, где один и тот же запрос компиллируется в цикле — а замеры на реальных приложениях.
V>Грубо, одну форму открыть — сотни ms только на компиляцию нескольких linq-запросов (обычно 3-5 на форму).
V>Приложение долго стартует (с заметной задержкой), долго открывает экраны (особенно, когда некий экран открывается в первый раз).
Хм. Надо профилировать.
V>И твой кодогенератор, когда впервые отрабатывает — тоже сам по себе тормозит, на JIT и всё прочее.Х
Это да — надо прогревать заранее. Там, где есть потенциальная возможность статической оптимизации, она есть — можно использовать то самое кэширование на старте.
Ну, а если стартап тоже важен, то включаем галочку "сохранять сборку", и код можно породить на стороне разработчика, а потом включить готовую сборку в поставку приложения.

V>Для примера, замена просто кода, типа:
V>

V>SomeScheme s1 = new ...;
V>s1.Add(a, b, "c");
V>s1.Add(e, f, "g");
V>...
V>s2.Add...
V>

V>На вручную сериализованные данные ускорило старт приложения с ~800 ms до ~200 ms, т.е. 600 ms отъедалось лишь на инициализацию, т.е. первый (и последний) прогон некоего кода, примерно эквивалентного показанному.
Я не знаю, что это за код, и почему он требует 600ms на исполнение.
V>(помню прошлые обсуждения с тобой, кое-какое представление о плюсовых шаблонах ты имеешь)
Ну и что?
V>Это если под x86.
И под ARM тоже.
V>Ты ведь курсе, например, что в природе нет активных поддерживаемых x86-х сборок Линукс?
V>Они все давно переползли на x86_x64, а там изкоробки 32 и 64-битные векторные операции, т.е. куча поколений, которые были для x86 — они пропущены для случая x86_x64.
А что насчёт 128 и 256? С 512 пока засада — нет поддержки в CLR.
V>Более поздние расширения могут пригодиться лишь в тех уникальных случаях, где надо оперировать векторами из памяти, длиной более 4-х (8 и 16), но это не твой случай, когда речь о представлении цвета.
С чего бы это вдруг? С цветами всё заработает прекрасно в AVX2.

V>Я тебе показывал хелперы даже для unsafe C#, просто чтобы показать идею.
V>На плюсах там в разы больше навертеть можно.
Угу, угу.
V>Если есть задача — под неё всё-равно хелперы писать надо.
V>Например, для оперирования цветами с альфа-каналами — свои хелперы.
Конечно.
V>Причём, от эффективности этих хелперов производительность зависит не меньше, чем от эффективности обхода массива.
И их можно сочетать с linq2d.
V>И откуда вообще взялось предположение, что под некий класс задач (буде он возник), не пишут соответствующие хелперы?
V>А то ты там свои навороты натурально с чистым Си сравнивал, разве ж это спортивно? ))
Давайте пример в студию — это будет конструктивно.

V>Тебе показывали реализацию на Питоне, которая не сложнее твоей на linq2d, зачем ты продолжаешь использовать тот аргумент, который уже бит?
Она медленнее

V>(как это делаю я, когда что-то с чем-то сравниваю)
Не вижу.

V>примерно такого плана: "вот видите, мы практически достигли производительности нейтива, хотя продолжаем оставаться в рамках высокоуровневого инструмента" и далее миллион вот этих бесконечнейших спекуляций на тему, "почему высокоуровневое лучше". Осталось выяснить, почему высокоуровневым может быть решение только на C#, а другим низзя? ))
Вы сначала покажите второе решение