Комментарии 135
13% — это, кстати, подоходный налог 100% одного потока из восьми.
Они меряли на MacOS а там Activity Monitor сообщает загрузку одного ядра. Т.е. процесс в AM может показывать и 200% если два ядра занимает.
Т.е. если привести это число к методике Windows (100% — загрузка всех ядер) то будет 1.5-3% что в общем согласуется с реальными цифрами.
Вот цифры на W10:
(там правда VS Code создает 6 процессов на это бедное окно, показан только rendering process)
Вот для сравнения Sciter c тем же Skia backend который использует Электрон.
Используется аналогичная по сложности структура экрана — редактор с подсветкой.
И для сравнения тот-же Sciter но c Direct2D backend:
Т.е. если привести это число к методике Windows (100% — загрузка всех ядер) то будет 1.5-3% что в общем согласуется с реальными цифрами.
Вот цифры на W10:
(там правда VS Code создает 6 процессов на это бедное окно, показан только rendering process)
Вот для сравнения Sciter c тем же Skia backend который использует Электрон.
Используется аналогичная по сложности структура экрана — редактор с подсветкой.
И для сравнения тот-же Sciter но c Direct2D backend:
6 процессов? Не потоков?
Именно процессов, cм: https://github.com/Microsoft/vscode/issues/5856
Это хромиум, он может.
НЛО прилетело и опубликовало эту надпись здесь
Когда мне опять будут мыть мозги веб-приложениями, SPA, Electron'ом и прочей ересью, буду в ответ кидать ссылку на этот пост.
Только ещё для полноты картины нужно вот этот ответ приводить:
If instead you are suggesting a fully native, non web stack based application: when you traverse the likely needs of a heavily themed, fully DPI independent, cross-platform application like VSCode, odds are that a non-native cursor substitute would be needed regardless.
If instead you are suggesting a fully native, non web stack based application: when you traverse the likely needs of a heavily themed, fully DPI independent, cross-platform application like VSCode, odds are that a non-native cursor substitute would be needed regardless.
Чего прям сразу fully native? Вон Eclipse и heavily themed, и cross-platform, и все остальное, и работает нормально.
Ситуация комичная конечно, но вот буквально вчера я отказался от WebStorm в пользу VS Code по причине… меньшего потребления ресурсов и лучшей стабильности последнего. Все очень неоднозначно, и огульно экстраполировать что-то одно на всю экосистему — большая ошибка, особенно для инженера.
экстраполировать что-то одно на всю экосистему — большая ошибка, особенно для инженера.
Которую совершаете и вы тоже, упоминая WebStorm. А я вот сейчас возьму и вспомню какой-нибудь Sublime, который, даже обмазанный плагинами на не самом эффективном питоне, уделывает по производительности и экономии памяти всех остальных)
Даже если это и баг, что курсор рендерится 60 фпс, то занятие им 13% процессора это ужас.
Я подозреваю, что существует какой-то обратный закон мура. Чем производительнее становятся компьютеры, тем неэффективнее становятся программы.
что существует какой-то обратный закон мураТут не совсем закон (в смысле того, что его просто так не выразить числами), но зависимость. Только есть ещё третий фактор — полная стоимость разработки. Грубо говоря, можно писать программы с той же эффективностью, что и в эпоху динозавров. Но это потребует намного более дорогих специалистов, больше времени на отладку и оптимизацию, более тщательного планирования разработки и т.д.
С другой стороны, можно применить закон Паркинсона об оценке ресурсов — «любая программа работает настолько плохо и медленно, насколько это вообще допустимо».
Грубо говоря, можно писать программы с той же эффективностью, что и в эпоху динозавров. Но это потребует намного более дорогих специалистов, больше времени на отладку и оптимизацию, более тщательного планирования разработки
Я не уверен, что намного. Многие из нас жили в эпоху динозавров и писали те самые программы, которые как-то ухитрялись работать, о боже, на 100МГц одноядерных Пентиумах с 16 Мб памяти (мои наручные часы с четырехядерным процем презрительно смотрят на эти характеристики). При этом работали зачастую шустрее, чем их аналоги сейчас. А главное, если иметь в виду не всякие там тяжелые вычисления, то и задачи решали примерно такие же. При этом какого-то качественного скачка в скорости разработки нового функционала с тех пор не произошло. Произошли изменения в подходе. Если, например, разработчик 1990-х хранил параметры приложения в ini-файле, и использовал для работы с ними нехитрый класс-обёртку, то разработчик 2010-х будет использовать xml-файл, а для работы с ним возьмет многомегабайтный парсер, который там будет уметь работать с коллекциями, поддерживать DOM, SAX, схемы документа, XML-трансформацию и много-много других в каком-то случае полезных вещей, но вот этот
Я не уверен, что намногоИменно что намного. Тут есть такой фактор как «количество людей, занятых разработкой в целом». Ещё 25 лет назад народ задумался о том, что постоянная стрельба в ногу за счет ручного управления памятью и прямого доступа к железу выходит слишком дорогой для энтерпрайза, а способа массово научить миллионы потребных разработчиков не стрелять себе в эти самые ноги на горизонте не видно. Причем получаемые решения страдали рядом фатальных недостатков — они были «неуниверсально оптимизированы» — вспомним хотя бы аттракционы «на каком видеоускорителе эта игра идет быстрее и не падает», и крайне неадаптированы к режиму «а сейчас мы этого гуру дорогого выгоним и посадим десяток людей с аутсорса» ввиду плохой документированности и общей требовательности к уровню понимания происходящего.
В итоге с одной стороны пошла тенденция загонять все и вся в сандбоксы разной степени виртуализированности, убирая прямой доступ к железу. С другой стороны, пошла тенденция под названием «да возьми библиотечную функцию — и не парься». Широко распространенные языки обзавелись богатейшими стандартными библиотеками, которые позволяют программировать прикладные задачи на уровне сборки кирпичиков из лего. Отдельно на это все натянули практически бесплатную кроссплатформенность на уровне этих самых библиотек, что позволяет нанимать на позицию «программиста под андроид или иос» человека, не совсем представляющего, как работает андроид или иос (и если кому-то кажется, что это ерунда, посмотрите, сколько прикладных виндоус-разработчиков могут описать как работает их операционка — хотя бы на уровне «что такое кольца защиты и почему Windows использует их два, а процессоры поддерживают четыре»).
И да, скорость разработки для продукта, который пишется на колене за несколько месяцев — это очень важно. Вот мне сейчас нужно написать несколько скриптов, вытаскивающих данные из багтрекера для аналитики. Написать мне их надо до конца дня. И хоть у багтрекера есть родной рест-апи, я все равно возьму библиотеку, оборачивающую этот рест-апи, т.к. на выходе я получу уже распарсенные и разложенные по полям и аттрибутам объекты, мне не надо писать все обработчики исключений на каждый возможный чих и мне не надо собирать результаты пачки запросов в один.
Во времена 100МГц пентиума я сравнил одну и ту же(!) программу на basic, рисовавшую фигуру лиссажу для соотношения частот 79:80 на экране 320x200 между qbasic и basic на ZX Spectrum. В котором были какие-то единицы мегагерц на 8-ми битном процессоре, устаревшем уже тогда лет на 10-15, кажется. Пентиум был быстрее, но раза так в 4-5 вместо ожидаемых мной 20-30 — в нем же уже был FPU и PCI шина к видеокарте и вообще…
Это наверное мое больное место, но мне кажется, что неэффективность еще может быть связана с распространением неподходящих инструментов. Как в свое время появился PHP — совершенно непродуманный примитивный язык, но настолько простой, что любой мог начать на нем программировать. Помню, несколько раз брался что-то править в проектах, написанных на PHP, и волосы вставали дыбом.
Несколько лет назад возникло похожее движение — Node.js и иже с ним. «Давайте все писать на Javascript, который никогда для этого не был предназначен! А главное, что даже ничего не понимая в компьютерах и программировании, можно сляпать огромное красивое приложение!»
В итоге, то, что в примерах выглядело хорошо (красивый функциональный код, мгновенная реакция на действия пользователя), в реальной жизни превратилось в кошмарных едва ворочающихся монстров.
Несколько лет назад возникло похожее движение — Node.js и иже с ним. «Давайте все писать на Javascript, который никогда для этого не был предназначен! А главное, что даже ничего не понимая в компьютерах и программировании, можно сляпать огромное красивое приложение!»
В итоге, то, что в примерах выглядело хорошо (красивый функциональный код, мгновенная реакция на действия пользователя), в реальной жизни превратилось в кошмарных едва ворочающихся монстров.
в JavaScript мерцающий курсор отнимает нормальные 1,2% ресурсов CPU
Нормальные? Т.е. всего 83 курсора сожрут современный процессор полностью?
А как курсоры мигали в 80-е и 90-е? На другие задачи, видимо, ресурсов уже не оставалось.
тогда использовали ардуино #sarcasm
Нет, основная часть этого времеи — не рендеринг курсора, а работа, общая для всех перерисовок. Посто мерцание курсора не даёт этим процессам «засыпать».
как курсоры мигали в 80-е и 90-е?
Были специальные курсорные сопроцессоры, а на мейнфреймах под это выделяли целые модули! Сейчас от этого ушли, в пользу программной эмуляции, но, видимо, зря.
Специально сверился с календарём. Нет не первое апреля…
Скажите, индустрии ПО крыш? Или еще можно спасти? (и индустрию, и честь процессора, которому не придется всю жизнь ишачить на курсор)
Скажите, индустрии ПО крыш? Или еще можно спасти? (и индустрию, и честь процессора, которому не придется всю жизнь ишачить на курсор)
К сожалению, с ростом вычислительных мощностей, такое отношение к потреблению ресурсов становится скорее нормой, чем отклонением. Спасти ситуацию можно, создавая быстрый эффективный код, и принципиально отказавшись от присказки «моё рабочее время стоит дороже чем планка оперативки/более мощный процессор».
Можно подумать, это сам разработчик решает, что «его рабочее время стоит дороже чем планка оперативки». Это решает рынок в целом и его руководитель/заказчик в частности.
Но говорят это почему-то именно разработчики. Зачастую, чтобы «сделать плохо» и «сделать хорошо» нужно одно и то же время — разница лишь в профессионализме разработчика. И хорошему разработчику хотя бы профессиональная гордость должна мешать делать плохо.
Хороший разработчик за свою работу берёт столько что часть заказчиков обращаются к плохим разработчикам.
Столкнувшись хоть раз со сколько-нибудь сложной системой — раз и навсегда понимаешь: "сделать хорошо" — невозможно. Всегда будет какой-то компромис, всегда "хорошо" будет только с какого-то одного ракурса. У хорошего разработчика не должно быть таких иллюзий. Это не значит, что все нужно делать абы как, это значит, что хороший разработчик должен уметь находить баланс и не абсолютизировать какой-то один аспект, будь то потребление ресурсов или что-то иное.
Сделать десктопное (десктопное, Карл!) приложение на HTML+JS это вообще за гранью добра и зла. Что помешало Microsoft сделать редактор кода используя более подходящие для этого языки и фреймворки? Ей-богу, это Web головного мозга какой-то…
Что помешало Microsoft сделать редактор кода используя более подходящие для этого языки и фреймворки?
Может быть это потому, что HTML+JS — работает на огромном количестве платформ (включая ARM), и скорость разработки у этой связки довольно неплохая. И HTML+JS как-раз оказался «более подходящим для этого языком и фреймворком»
Хотя нет, вы правы конечно, что там эти м*даки в MS понимают в создании приложений… Как обычно наверное какой-то джуниор предложил «А давайте на HTML писать», и все такие «А давайте!»
Можно подумать разработчик это новая форма рабского права, за которого все решает заказчик.
Раньше была шутка, что разработчик программы, обслуживающей лампочку капслока, считает, что все ресурсы компьютера в его распоряжении.
Сейчас это точно уже не шутка.
Сейчас это точно уже не шутка.
Но ведь в данном случае не нужен быстрый код
Нужен просто код, работающий *логично*, черт возьми! ))
Т.е. такой, который не перестраивает, и не перерисовывает всю матрёшку интрефейса при каждом жалком мигании жалкого курсорчика. Речь же совсем не о производительности.
Нужен просто код, работающий *логично*, черт возьми! ))
Т.е. такой, который не перестраивает, и не перерисовывает всю матрёшку интрефейса при каждом жалком мигании жалкого курсорчика. Речь же совсем не о производительности.
Вот до чего довел Node.js головного мозга. К сожалению, все чаще вижу приложения на Electron. Да, все круто выглядит, только медленно работает, и отжирает половину ресурсов ноутбука. Особенно обидно, когда приложение имеет вспомогательный характер. Скоро дойдет до того, что часы в трее будут требовать не менее 4 Гб RAM и отъедать 15% CPU на отрисовывание секунд. :(
Вы только что описали схему работы значительной части modern ui приложений в восьмерке и десятке. 100 мегабайт ОЗУ на low-res приложение погоды, входящей в поставку Винды? Запросто. 25% от CPU? Как два пальца об асфальт. Очередь 5400 RPM диска на 3 секунды? Да каждый божий день.
Ах да. Без более-менее быстрого GPU десятка (т.е. со стандартным VGA-драйвером) еще безбожно тормозит, отрисовывая интерфейс.
Особенно весело видеть, как какой-то слак отжирает полтора гигабайта рамы.
Ну не знаю, сильно зависит от разработчика. Тот же телеграм под декстоп просто летает и совершенно не тормозит.
Удивительно, но запускается он, будучи написанным на Qt, медленнее Chromium.
Каждый день вот замечаю, почти одновременно их запуская (Telegram Desktop раньше, но всё равно его окно вижу позже, и речь о секундах).
Каждый день вот замечаю, почти одновременно их запуская (Telegram Desktop раньше, но всё равно его окно вижу позже, и речь о секундах).
Хм, странно. Может это только системный телеграмм тормозной? Или что-то не так с системой.
Я пользуюсь портативной (standalone) версий, так даже при запуске с обычного диска или USB флешки (не SSD), даже на WinXP и относительно старых процессорах уровня Core 2 или Phenom запускается в пределах 1-2 секунд
Правда контактов и истории сообщений в нем мало, т.к. редко им пользуюсь.
Я пользуюсь портативной (standalone) версий, так даже при запуске с обычного диска или USB флешки (не SSD), даже на WinXP и относительно старых процессорах уровня Core 2 или Phenom запускается в пределах 1-2 секунд
Правда контактов и истории сообщений в нем мало, т.к. редко им пользуюсь.
Или что-то не так с системой.
Хороший SSD под рут, хорший HDD под
/home, Intel i5 и i7.Я пользуюсь портативной (standalone) версий, так даже при запуске с обычного диска или USB флешки (не SSD), даже на WinXP и относительно старых процессорах уровня Core 2 или Phenom запускается в пределах 1-2 секунд
Примерно такие ощущения: Chromium — 1–2 секунды до появления окна, Telegram Desktop — 3–4 секунды. Telegram Desktop запускается первым, повторюсь, но окно появляется позже.
Может и в истории дело, не знаю точно, но мне кажется вряд ли.
Я имел ввиду не железо (по железу даже на Core 2 + 2 ГБ памяти очень шустро работает, так что любого кроме совсем антикварного должно хватать), а ОСь и системное ПО. Но наверно все-таки дело истории.
Если есть винда как 2я система можно сравнить, я вот этой версией пользуюсь (установки не требует, просто запускается из любой папки): https://telegram.org/dl/desktop/win_portable
Если есть винда как 2я система можно сравнить, я вот этой версией пользуюсь (установки не требует, просто запускается из любой папки): https://telegram.org/dl/desktop/win_portable
Боже мой 13%.) Когда в Windows запускаешь любую прогу от apple(iTunes, QuickTime), то о таком можно только мечтать. А тут ещё темболее такая ядерная смесь MacOS, JS, CSS.
и какое отношение mac os имеет ко всему этому?
Человек думает, что в макоси itunes тоже тормозит.
Проблема не в электроне как таковом, а в архитектуре самого редактора. Я не понимаю какой смысл реализовывать поле реактора через html теги — не для этого они предназначены. В данном случае идет постоянное изменение DOM.
Что мешало Microsoft использовать canvas — непонятно.
Что мешало Microsoft использовать canvas — непонятно.
Индусский код такой индусский! С тех пор как Microsoft возглавляет Сатья Наделла — корпорация регрессирует убыстряющимися темпами. И если Билли не успеет вовремя распродать свои акции, то они из богатейшего человека рискует превратиться в нищего.
Всё идет по старому.
В данном случае индусский код написали в гугле. И далеко не только микрософт напоролись на эту осовенность.
Вопрос еще в адекватности людей, пишущих десктопные приложения на JavaScript. Может ещё навигационное ПО для самолетов на нем начнут писать…
Было бы апи для управления самолётом — я бы с удовольствием написал ;-)
Crew Dragon в космос полетел под управлением js и на тачскрине
Не под управлением JS, а с UI'ем консоли управления на JS. При этом консоль, по факту, можно и не пользоваться, в 99% времени она нужна только для контроля показателей, корабль и сам отлично умеет летать туда и обратно и стыковаться в том числе (что и делает регулярно в грузовой версии).
Хотя, ручные режими, в принципе, там тоже через неё управляются, но ими пользуются исключительно с целью «попрактиковаться, на случай чего».
Хотя, ручные режими, в принципе, там тоже через неё управляются, но ими пользуются исключительно с целью «попрактиковаться, на случай чего».
«Чукча не читатель, чукча писатель»? Root cause проблемы — баг в Google Chrome, а не в Microsoft VS Code.
Что касается того, что сейчас происходит с Microsoft — я очень надеюсь, что они будут продолжать движение в ту же сторону. Тот Microsoft, что был при Баллмере, и тот, что есть сейчас — это две большие разницы, и тот, что сейчас, мне нравится куда больше. И Билли, думаю, тоже вполне щастлив тому, что при Наделле акции MSFT (которые при Баллмере в лучшем случае колебались на одном уровне) растут в цене, как на дрожжах.
Что касается того, что сейчас происходит с Microsoft — я очень надеюсь, что они будут продолжать движение в ту же сторону. Тот Microsoft, что был при Баллмере, и тот, что есть сейчас — это две большие разницы, и тот, что сейчас, мне нравится куда больше. И Билли, думаю, тоже вполне щастлив тому, что при Наделле акции MSFT (которые при Баллмере в лучшем случае колебались на одном уровне) растут в цене, как на дрожжах.
Ну все, значит естетвенный отбор в IT поощряет мигающий курсор, отжирающий 13% ресурсов процессора и редактор кода, занимающий 8 Гб… Nothing to do here
Называть Visual Studio редактором кода — это как назвать Windows «браузером для веб». Это, мягко говоря, передергивание правды.
Про то, что оно весит дофига, спору нет — это потому, что и ставится дофига. Что было частично исправлено в VS 2017 (компоненты стали более гранулярными, и можно более детально выбрать, что ставить и что нет); моя установка весит меньше 4 Гб.
Про то, что оно весит дофига, спору нет — это потому, что и ставится дофига. Что было частично исправлено в VS 2017 (компоненты стали более гранулярными, и можно более детально выбрать, что ставить и что нет); моя установка весит меньше 4 Гб.
моя установка весит меньше 4 Гб.
Всё это понятно, но… она умеет делать принципиально что-то более сложное, чем, например, Visual Studio 6, которая весила раз в двадцать меньше? Причём я не имею в виду библиотеки, я только про саму IDE.
Из того, что я использовал — Intellisense, дебаггер нативного кода стали несравнимо лучше; добавились поддержка и отладка DirectX и GPGPU, .NET, ASP.NET/HTML/CSS/JS (и тд. — веб), мобильная разработка для Winphone и Android, включая эмуляторы и отладку, средства баз данных, толпы энтерпрайз-фич, которыми я не пользовался и тд.
Из того, что я использовал — Intellisense, дебаггер нативного кода стали несравнимо лучше
Да, но оно же, никак не тянет на многократную разницу в размере и прожорливости ресурсов. Я ещё в Delphi 6 полтора десятилетия назад успешно отлаживал веб-приложения. Она слегка притормаживала на Celeron 700 с 128Мб ОЗУ. Студия там вообще летала. А сейчас у меня 16 Гб, 8 ядер, скоростной NVMe SSD, и она, зараза такая, на всём этом лагает.
Корень проблем лежит в кроссплатформенности. Платформы плодятся как грибы после дождя, производители не желают слышать ни о каких стандартах и ни о какой совместимости, фрагментированность устройств только растёт.
У разработчиков просто нет выхода, кроме как вводить по 6 слоёв абстракций, если они хотят, чтобы единожды написанное приложение работало на максимально возможном количестве устройств.
А эти абстракции, естественно, обходятся весьма недёшево.
Была бы всего одна десктопная платформа и одна мобильная, со строго стандартизированным набором устройств и двумя-тремя разрешениями экрана, так городить абстракции и не потребовалось бы.
У разработчиков просто нет выхода, кроме как вводить по 6 слоёв абстракций, если они хотят, чтобы единожды написанное приложение работало на максимально возможном количестве устройств.
А эти абстракции, естественно, обходятся весьма недёшево.
Была бы всего одна десктопная платформа и одна мобильная, со строго стандартизированным набором устройств и двумя-тремя разрешениями экрана, так городить абстракции и не потребовалось бы.
Visual Studio — исключительно виндовая программа.
Корень проблем лежит в кроссплатформенности.
Мне кажется, корень проблем лежит в раздутых библиотеках. Когда один и тот же код дублируется, для выполнения простейших задач тянутся многомегабайтные либы, которые под руку подвернулись, и т.д. Просто потому, что фокус сместился с «писать так, чтобы был баланс между скоростью разработки и качеством софта» в сторону «писать как можно быстрее и дешевле». Кроссплатформенный код изобрели не вчера, та же Qt вопросы абстрагирования от Win32 и posix/Xwindow успешно закрывала и без малого 20 лет назад, и при этом приложения не были такими огромными.
Ну хорошо, пусть будет гордо и красиво "среда разработки", суть не особенно меняется: например среда разработки Eclipse весит в 20 раз, IDEA — тоже самое.
В выборе технологии у них баг был. Но, судя по Win10, этот баг без смены курса развития / всего топ-менеджмента MS — не починить.
Правда, конечно, странно, что они стали использовать гугл хромиум вместо своего .NET к примеру. Это какой-то странный MS.
Правда, конечно, странно, что они стали использовать гугл хромиум вместо своего .NET к примеру. Это какой-то странный MS.
Что за ушлепки придумали интерфейс в десктопной системе на базе веб-технологий делать? Я конечно понимаю, что можно гораздо проще делать красиво и переносимо, но мне нужна функциональность. Меня на работе уже какахами закидали из-за 2013-2016 MS Office, который виснет из-за каждого чиха на i5.
Хотя, казалось бы, с ресурсами MS можно и человеческое native приложение сделать.
Ужас в том, что кроссплатформенный софт на html рисуется шустрее, чем на java, что вообще кажется странной дикостью. Но вот если сравнить скорость отрисовки текста в vs code и qt creator, то последний рвет как тузик грелку.
Жаль только, что там плагины подвозить на лету нет возможности, да и нет поддержки кучи языков.
Хотя вот, справедливости ради, пробовал всего из себя нативного Gnome Builder, а он, оказывается, тормознее, чем VS Code, так, что все тормоза от плохих алгоритмов и архитектуры, а не от используемого языка.
Я конечно все понимаю, cross-platform, web-stack. Куча веб программистов которых можно запрячь за дешево. Работает и сойдет что не очень быстро.
Но люди, человеки, остановитесь. Аппликации которые тянут за собой целый веб стэк, даже если они из себя представляют две кнопки. Тормоза UI, потому как вместо использования встроенных библиотек операционной системы, все виртуализируется по пять раз. Ладно еще память, ее не жалко, но процессоры то уже давно не резиновые, с учетом что на оптимизацию давно все забили.
Но люди, человеки, остановитесь. Аппликации которые тянут за собой целый веб стэк, даже если они из себя представляют две кнопки. Тормоза UI, потому как вместо использования встроенных библиотек операционной системы, все виртуализируется по пять раз. Ладно еще память, ее не жалко, но процессоры то уже давно не резиновые, с учетом что на оптимизацию давно все забили.
Вы еще не программируете визуальщину на дельфи?
Тогда мы идем к вам!
Ни единого тормоза, лага, провисания fps и т.д… минимум памяти и процессора, все летает.
И пусть будет 2005 год вечно, ничего лучше все равно не придумают.
А теперь можно минусить до 1000, но это ничего не изменит же в убогом недомозге современных недопрограммистов :)
Тогда мы идем к вам!
Ни единого тормоза, лага, провисания fps и т.д… минимум памяти и процессора, все летает.
И пусть будет 2005 год вечно, ничего лучше все равно не придумают.
А теперь можно минусить до 1000, но это ничего не изменит же в убогом недомозге современных недопрограммистов :)
И все эти екзешники, скомпилированные в далёком начале 2000-х годов, весящие от 250 кб и не имеющие никаких внешних зависимостей, до сих пор отлично запускаются и работают хоть на Вин 98, хоть на десятке. Говорите, проблемы с масштабируемостью под высокую плотность пикселей? Да Win 8 без бубна из коробки не способна отрендерить чёткий незамыленный шрифт. Если всё изначально сломано под капотом самой ОС, незачем винить софт пятнадцатилетней давности.
Слезу пустил'((
Вам там в 2005-м хорошо, у вас по сути всего одна популярная ОС и всего одна платформа.
А теперь попробуйте запустить Delphi-приложение под Linux и MaxOS. Тут, внезапно, Lazarus соберёт бинарник куда как большего размера, чем дельфийские 250 Кб, да и работать оно будет не так шустро, и памяти выжрет побольше.
А что, если приложение нужно запускать ещё и на ARM-процессорах? А если на мобильных устройствах/планшетах?
Чем выше кроссплатформенность, тем больше весит приложение и тем менее эффективно оно использует ресурсы. QtCreator+QML — и вот оно уже тормозит вполне прилично. Добавим PyQt, и тормозов ещё больше. А переход к веб-приложениям просто ещё один шаг на этом пути.
Проблему можно решить исключительно дефрагментацией аппаратной части, но это из области фантастики, поэтому можно смело считать, что на данном этапе развития IT проблема неразрешима.
А теперь попробуйте запустить Delphi-приложение под Linux и MaxOS. Тут, внезапно, Lazarus соберёт бинарник куда как большего размера, чем дельфийские 250 Кб, да и работать оно будет не так шустро, и памяти выжрет побольше.
А что, если приложение нужно запускать ещё и на ARM-процессорах? А если на мобильных устройствах/планшетах?
Чем выше кроссплатформенность, тем больше весит приложение и тем менее эффективно оно использует ресурсы. QtCreator+QML — и вот оно уже тормозит вполне прилично. Добавим PyQt, и тормозов ещё больше. А переход к веб-приложениям просто ещё один шаг на этом пути.
Проблему можно решить исключительно дефрагментацией аппаратной части, но это из области фантастики, поэтому можно смело считать, что на данном этапе развития IT проблема неразрешима.
НЛО прилетело и опубликовало эту надпись здесь
Как минмиум, мобильные приложения должны быть точно отдельными, а не пытаться использовать один дизайн для всех платформ.
И тут не «чем больше кроссплатформенность», просто не надо использовать интерпретируемые языки там, где нужна производительность.
И тут не «чем больше кроссплатформенность», просто не надо использовать интерпретируемые языки там, где нужна производительность.
Они не совсем интерпретируемые, там ведь JIT, и он работает вполне неплохо.
Проблемы тут другие. Во-первых, в большинстве современных языков напрочь отсутствует такая вещь, как линкер. Вы не можете, как во времена C++, выбрать из библиотеки только используемый код. Если из всей библиотеки вам нужна всего одна функция, библиотека всё равно будет включена в проект целиком. Современные проекты состоят по большей части из мёртвого кода, который никогда не выполняется — такова плата за отсутствие статической типизации и возможность динамической компоновки произвольных объектов, структура которых точно неизвестна на момент сборки проекта.
Во-вторых, автоматическое управление памятью, т.е. сборщик мусора. Существует даже расхожая шутка, мол Java догонит по быстродействию C++, как только изобретут компьютер с бесконечным количеством памяти.
Языки со сборкой мусора всегда будут жрать существенно больше памяти и притормаживать в моменты, когда отрабатывает этот самый сборщик.
Проблемы тут другие. Во-первых, в большинстве современных языков напрочь отсутствует такая вещь, как линкер. Вы не можете, как во времена C++, выбрать из библиотеки только используемый код. Если из всей библиотеки вам нужна всего одна функция, библиотека всё равно будет включена в проект целиком. Современные проекты состоят по большей части из мёртвого кода, который никогда не выполняется — такова плата за отсутствие статической типизации и возможность динамической компоновки произвольных объектов, структура которых точно неизвестна на момент сборки проекта.
Во-вторых, автоматическое управление памятью, т.е. сборщик мусора. Существует даже расхожая шутка, мол Java догонит по быстродействию C++, как только изобретут компьютер с бесконечным количеством памяти.
Языки со сборкой мусора всегда будут жрать существенно больше памяти и притормаживать в моменты, когда отрабатывает этот самый сборщик.
QtCreator+QML — и вот оно уже тормозит вполне прилично.
Qt Creator — это среда разработки, каким образом она влияет на тормоза конечного продукта? А QML достаточно бодро работает, если уметь его готовить.
Добавим PyQt, и тормозов ещё больше.
Пользуюсь приложением на PyQt — тормозов не заметил.
Вот вам и ынтырпрайз. Русский ваня быстренько бы заменил step-start на steps(10) и брат был бы жив. А эти консилиум собирают.
Я еще могу вспомнить что в старом добром текстовом режиме 80*25 символов мигающий курсор рендерился аппаратно в видеокарте, что потребляло 0% процессорного времени. Вот так вот… вполне кроссплатформенно кстати:)
А теперь веб на вебе, я конечно и сам понимаю что веб это настоящее и будущее (и сам активно изучаю веб технологии) но создавать на веб стеке среды разработки это ИМХО перебор. Все должно применяться по своему назначению и никак иначе. Веб — для веба, нативные приложения — для тяжелых задач в оффлайне.
А теперь веб на вебе, я конечно и сам понимаю что веб это настоящее и будущее (и сам активно изучаю веб технологии) но создавать на веб стеке среды разработки это ИМХО перебор. Все должно применяться по своему назначению и никак иначе. Веб — для веба, нативные приложения — для тяжелых задач в оффлайне.
Хм, я один пропустил момент когда Visual Studio стал запускать на Маке?
Visual Studio Code и Visual Studio — совершенно разные программы.
Первое — под капотом Хромиум и javascript. Потому и запускается на трёх OS, и плагины кроссплатформенные.
Первое — под капотом Хромиум и javascript. Потому и запускается на трёх OS, и плагины кроссплатформенные.
Ну вообще правда пропустили.
https://www.visualstudio.com/vs/visual-studio-mac/
А вот был бы там нормальный сценический граф, он бы сразу понял, что достаточно просто перестроить только один жалкий узел.
Напомнило — почему из Windows убрали мигающее двоеточие и секунды в таскбаре —
https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=42203
https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=42203
Выглядит ужасно, но я так понимаю, что это не вина MS, Electron основан на детище Google, который и обеспечивает отрисовку.
С другой стороны, увлечение Electron'ом понятно: как ещё можно сделать кросплатформенное приложение с поддержкой тем оформления без необходимости рисовать UI для каждой ОС отдельно с помощью native-технологий. А вот серьезно — может кто-нибудь что-то подобное подсказать?
С другой стороны, увлечение Electron'ом понятно: как ещё можно сделать кросплатформенное приложение с поддержкой тем оформления без необходимости рисовать UI для каждой ОС отдельно с помощью native-технологий. А вот серьезно — может кто-нибудь что-то подобное подсказать?
Всегда мечтал наблюдать мигающий курсор в 60фпс. Это же такая плавная картинка.
Кстати, а почему именно 60? Всинк? А если у меня монитор 75гц? А если 120? Сожрет четверть производительности цп на отрисовку курсора?
Наткнулся на эту статью. Прошло три года. VS Code вешает не самый слабый ноутбук, когда пилю всего лишь один небольшой JS-проект
Сегодня задался вопросом отчего в Windows в некоторых приложениях курсор мигает 5 раз, а в некоторых бесконечно.
В Windows 10 версии 1709 в стандартных приложениях (Проводник, Блокнот, и т. п.) курсор перестаёт мигать через несколько секунд. Это значение хранится в реестре по адресу HKEY_CURRENT_USER\Control Panel\Desktop\CaretTimeout в формате DWORD. По умолчанию — 5000 мс. Если указать ffffffff, то будет мигать бесконечно, но, очевидно, это сказывается на сроке жизни аккумулятора.
Chromium-based приложения (в том числе Edge) этот параметр игнорируют, поэтому мигают бесконечно.
В Linux это значение зачастую тоже ограничено, например, у GTK-приложений оно равно 10.
В Windows 10 версии 1709 в стандартных приложениях (Проводник, Блокнот, и т. п.) курсор перестаёт мигать через несколько секунд. Это значение хранится в реестре по адресу HKEY_CURRENT_USER\Control Panel\Desktop\CaretTimeout в формате DWORD. По умолчанию — 5000 мс. Если указать ffffffff, то будет мигать бесконечно, но, очевидно, это сказывается на сроке жизни аккумулятора.
Chromium-based приложения (в том числе Edge) этот параметр игнорируют, поэтому мигают бесконечно.
В Linux это значение зачастую тоже ограничено, например, у GTK-приложений оно равно 10.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Visual Studio Code отнимает 13% ресурсов CPU из-за мерцания курсора