приложения на WPF такие же тормозные, как на электроне
Да кто же виноват в вашей выборке? ) Посмотрите вот на моё поделие, там правда не впф, а авалония. Но всё равно замл. Работает с такими объёмами данных и с такой скоростью, какие просто невозможны на электроне.
Странные выводы. Вся ветка про то, что надо делать нативные приложения вместо кучи обёрток в виде электрона и интерпретируемого HTML (тоже подвид XML). Я вот и напомнил про компилируемый язык. А вы предлагаете пойти по пути электрона - опять использовать интерпретацию.
Хранить разметку в виде кода, и декомпилировать перед каждым редактированием - странная идея.
Во-первых это работает. Во вторых не обязательно в винформс упираться. Есть axaml, например, на который я очень толсто намекаю. Там хранится модель разметки, а при компиляции приложения из модели генерируется код.
Не находите, что где-то здесь находится корреляция? Тормозить оно может, тормозить может что угодно вообще. Зависит от того, как это использовать. Возвращаясь к теме нативности, замл намного ближе к железу, чем HTML. И работает быстрее на тех же задачах. Хотя бы в силу компилированности в рантайме и прямой связке с языком. Впрочем, я не хотел бы, чтобы спор упирался в замл. У того же дотнета есть и веб-решения. Классический разор и фактически стриминговый блазор.
Я говорил про C#. На нём можно писать близко к железу, причём с небывалым удобством. Change my mind.
Нет wysiwyg-дизайнера в Visual Studio
Скрытый текст
Разработчики WinForms не код пишут, а контролы перетаскивают мышкой с тулбаров и меняют им свойства в редактилках
Я забыл предупредить, я с винформс уже как 15 лет работаю ) Там да, есть привычка в визуальном редакторе редактировать. Но это не имеет никакого отношения к декларативности.
При сохранении это уже сериализуется в императивный код, при загрузке снова парсится - кринж.
Никуда оно не парсится при загрузке. Оно один раз компилируется в исполняемый код и всё. Дальше выполняется. И не ясно, что для вас кринж. Что wysiwyg в конечном итоге превращается в набор команд? А как иначе может быть?
Честно говоря никогда не пробовал. У меня не было задачи сделать шарп быстрее, он и так достаточно хорош. Но я знаю, что AvaloniaUI поддерживает Native AOT.
XAML это не HTML. Он выглядит, как HTML, но это компилируемый язык со всеми вытекающими. Вообще странно их сравнивать. XAML это не только разметка, но и биндинги.
Для создания UI нужна специальная подсистема (WinForms или WPF)
UWP, MAUI. Есть кроссплатформенная AvaloniaUI, которая, кстати, умеет в AOT. Авалония НЕ работает с нативным API, а рисует сама. Есть экзотика вроде Qt/.NET или ImGui.NET.
Есть Unity и Godot для игр. Есть OpenTK для работы с OpenGL/CL.
декларативное описание UI сериализуется в императивный код
Не понял пассажа. Когда у винформс было декларативное описание?
У вас в самом вопросе указана марка ракет. Это предвзятость. Если расширить вопрос до "люди, накидывающие ракетами по застройке с гражданским населением", то предвзятость исчезнет. Но суть вопроса останется.
Тепмература ОЖ ДВС - около 90 градусов. То, что радиатор кондея поднимет температуру воздуха на десяток градусов погоды не сделает. Тут ключевой момент - включенный обдув вентилятором. Сброс тепла намного быстрее происходит.
А ещё помню, у меня клинил термостат, и ОЖ гонялась по внутреннему кругу. Движку было горячевато. Чтобы до сервиса доехать, врубил кондей на полную и печку. Печка сбрасывала тепло в воздуховоды, кондей отводил на радиатор под капотом. Так и доехал)
У меня когда-то был профи с аж целым мегабайтом на борту. И для меня осталось без ответа два вопроса к экрану:
Зачем такую сложную адресацию сделали? Это же реально неудобно. Для рисования графики сделали систему адресации спектрума ещё сложнее, ещё неудобнее, а с другой стороны, поломали удобство рисования символов 8х8. Зачем?
Сделали аттрибут для линии 8х1 вместо 8х8. С одной стороны увеличили объём аттрибутов в восемь раз, сравняв с bitfield, а с другой так и не сделали индивидуальные цвета в пикселях. Ну почему? Всего вдвое увеличить объём видеопамяти и были бы полноценные картинки. Уж профик 512 (тем более мегабайт) мог бы себе позволить.
В итоге экран профика оказался такой "ни рыба ни мясо". Для демомейкинга слишком толстый и неповоротливый, для работы с текстом впрочем тоже. Для графики слишком сложный и геморройный из-за неоправданных цветовых аттрибутов. Три цвета в линии 8х1 не нарисуешь.
Вы сами всё написали, ещё и с примерами. В кириллице 33 буквы, в латинице 26. Если вычесть специфичные буквы вроде "W", "X", "Q", получится, что у трети кириллицы нет прямой транслитерации. Можно транслитерировать в сочетания букв, но тут опс: у каждой буквы в сочетании уже есть обратная прямая замена. Выходит, что даже чисто математически - транслитерация операция необратимая.
Проверять конечно надо. Но я думаю, что результат совершенно предсказуем при наличии векторных операций или каком-либо кэше.
Вы абсолютно правы, что ваш алгоритм лучше для минимизации времени каждой выборки. Собственно, я подумал, а можно ли уменьшить максимальное время выборки и думал в сторону размазывания сдвига по операциям записи. Получился тот же алгоритм, что у вас.
Но. Можно сделать ещё лучше. Так сказать объединить алгоритмы. Если у нас известна кратность копирования (например копируется по 128 бит, а юнит у нас инт в 32 бита), то можно писать через 4 записи. Так же дважды, как предлагали.
Да кто же виноват в вашей выборке? ) Посмотрите вот на моё поделие, там правда не впф, а авалония. Но всё равно замл. Работает с такими объёмами данных и с такой скоростью, какие просто невозможны на электроне.
Странные выводы. Вся ветка про то, что надо делать нативные приложения вместо кучи обёрток в виде электрона и интерпретируемого HTML (тоже подвид XML). Я вот и напомнил про компилируемый язык. А вы предлагаете пойти по пути электрона - опять использовать интерпретацию.
Во-первых это работает. Во вторых не обязательно в винформс упираться. Есть axaml, например, на который я очень толсто намекаю. Там хранится модель разметки, а при компиляции приложения из модели генерируется код.
XAML - это подвид XML. Дальше что процессору делать с этим XML?
Мне понятно. Даже понятно, переживёт или нет. Во всех *.designer.cs большими буквами написано "ничего не пхать сюдой - перезапишется"
Не находите, что где-то здесь находится корреляция? Тормозить оно может, тормозить может что угодно вообще. Зависит от того, как это использовать. Возвращаясь к теме нативности, замл намного ближе к железу, чем HTML. И работает быстрее на тех же задачах. Хотя бы в силу компилированности в рантайме и прямой связке с языком. Впрочем, я не хотел бы, чтобы спор упирался в замл. У того же дотнета есть и веб-решения. Классический разор и фактически стриминговый блазор.
Я говорил про C#. На нём можно писать близко к железу, причём с небывалым удобством. Change my mind.
Скрытый текст
Я забыл предупредить, я с винформс уже как 15 лет работаю ) Там да, есть привычка в визуальном редакторе редактировать. Но это не имеет никакого отношения к декларативности.
Никуда оно не парсится при загрузке. Оно один раз компилируется в исполняемый код и всё. Дальше выполняется. И не ясно, что для вас кринж. Что wysiwyg в конечном итоге превращается в набор команд? А как иначе может быть?
Честно говоря никогда не пробовал. У меня не было задачи сделать шарп быстрее, он и так достаточно хорош. Но я знаю, что AvaloniaUI поддерживает Native AOT.
XAML это не HTML. Он выглядит, как HTML, но это компилируемый язык со всеми вытекающими. Вообще странно их сравнивать. XAML это не только разметка, но и биндинги.
UWP, MAUI. Есть кроссплатформенная AvaloniaUI, которая, кстати, умеет в AOT. Авалония НЕ работает с нативным API, а рисует сама. Есть экзотика вроде Qt/.NET или ImGui.NET.
Есть Unity и Godot для игр. Есть OpenTK для работы с OpenGL/CL.
Не понял пассажа. Когда у винформс было декларативное описание?
Ещё какое! Если взять C#, то у него очень развитые инструменты, очень большое коммьюнити, гигантское количество библиотек.
Если считаете, что IL - это недостаточно нативно, то существует Native AOT.
У вас в самом вопросе указана марка ракет. Это предвзятость. Если расширить вопрос до "люди, накидывающие ракетами по застройке с гражданским населением", то предвзятость исчезнет. Но суть вопроса останется.
И при этом вопрос заиграет новыми красками.
Тепмература ОЖ ДВС - около 90 градусов. То, что радиатор кондея поднимет температуру воздуха на десяток градусов погоды не сделает. Тут ключевой момент - включенный обдув вентилятором. Сброс тепла намного быстрее происходит.
А ещё помню, у меня клинил термостат, и ОЖ гонялась по внутреннему кругу. Движку было горячевато. Чтобы до сервиса доехать, врубил кондей на полную и печку. Печка сбрасывала тепло в воздуховоды, кондей отводил на радиатор под капотом. Так и доехал)
Тут самый главный вопрос: на какие форс-мажоры и сколько.
Так удобнее )
Скрин IDE в 4К
У меня когда-то был профи с аж целым мегабайтом на борту. И для меня осталось без ответа два вопроса к экрану:
Зачем такую сложную адресацию сделали? Это же реально неудобно. Для рисования графики сделали систему адресации спектрума ещё сложнее, ещё неудобнее, а с другой стороны, поломали удобство рисования символов 8х8. Зачем?
Сделали аттрибут для линии 8х1 вместо 8х8. С одной стороны увеличили объём аттрибутов в восемь раз, сравняв с bitfield, а с другой так и не сделали индивидуальные цвета в пикселях. Ну почему? Всего вдвое увеличить объём видеопамяти и были бы полноценные картинки. Уж профик 512 (тем более мегабайт) мог бы себе позволить.
В итоге экран профика оказался такой "ни рыба ни мясо". Для демомейкинга слишком толстый и неповоротливый, для работы с текстом впрочем тоже. Для графики слишком сложный и геморройный из-за неоправданных цветовых аттрибутов. Три цвета в линии 8х1 не нарисуешь.
???
Так и на чём?
Я теперь понял, что вы сделали. Вы превратили j, y, h в префиксы и постфиксы, не используя их в обратной транслитерации.
То, что вы сделали, действительно может помочь в цели полной обратной совместимости. За счёт читаемости. Но у меня вопрос, а зачем?
Кстати, у вас "y" и "h" используются и как префикс и как постфикс. Соответственно, возможны коллизии.
Yod это ёд или йод? Окей, если не брать эрративы Pasha это пасха или Паша?
Вы сами всё написали, ещё и с примерами. В кириллице 33 буквы, в латинице 26. Если вычесть специфичные буквы вроде "W", "X", "Q", получится, что у трети кириллицы нет прямой транслитерации. Можно транслитерировать в сочетания букв, но тут опс: у каждой буквы в сочетании уже есть обратная прямая замена. Выходит, что даже чисто математически - транслитерация операция необратимая.
Нет
Мммм, пахнуло Мари Кондо. Для диайвайщика это очень плохой совет.
Минусы ставят ввиду абсолютной бессмысленности статьи. Ну и плюс реклама телеграм-канала. Вместе оно понятно, зачем вообще автор здесь.
Проверять конечно надо. Но я думаю, что результат совершенно предсказуем при наличии векторных операций или каком-либо кэше.
Вы абсолютно правы, что ваш алгоритм лучше для минимизации времени каждой выборки. Собственно, я подумал, а можно ли уменьшить максимальное время выборки и думал в сторону размазывания сдвига по операциям записи. Получился тот же алгоритм, что у вас.
Но. Можно сделать ещё лучше. Так сказать объединить алгоритмы. Если у нас известна кратность копирования (например копируется по 128 бит, а юнит у нас инт в 32 бита), то можно писать через 4 записи. Так же дважды, как предлагали.