Comments 66
А вот за лаги мобильных устройств типа «скролил экран, он тупит, нажал на экранную кнопку, но экран сдвинулся дальше, и в области нажатия оказалась совсем другая кнопка» создателей этих устройств надо вешать на фонарях. Особенно «весело» с такими закидонами серфить по инету без адблока.
Даже эффективные грамотные фреймворки дают огромный ненужный оферхед.
У мобильников основное торможение из-за нехватки памяти и множества не оптимизированных фоновых процессов.
В итоге те решения, которые срабатывали мгновенно в TurboVision 25 лет назад на 486 ныне неспешно по 1-2 секунды реагируют на нажатия мыши.
Samsung S3, Mac Book Pro 2014, список литературы, в котором на первом месте статья из прошлого века.
Вы серьёзно?
p.s. с самим посылом я в целом согласен
p.p.s. да, я видел что это первож
Я не утверждаю что статья рудиментарная, но видеть ее вверху списка немного странно. Хотя бы потому что понятие «интерактивная система» существенно изменилась за последние 22 года.
К примеру, в 96 году IDE с обыкновенным, не очень умным автодополнением, — это было уже что-то почти фантастическое (если вообще было), а сейчас считается нормальным иметь real-time solution-wide-error-analysis и фоновое исполненение юнит тестов. Просто другой уровень...
Психологический эффект наверное такой же остался, но производительность работы с компьютером возросла на порядки — даже с учётом «тормозов». Я бы не хотел променять все эти современные нововведения на интерфейс с около-нулевой задержкой.
а сейчас считается нормальным иметь real-time solution-wide-error-analysis и фоновое исполненение юнит тестов
Это всё ещё фантастика на сколь-нибудь больших проектах, когда запускаешь анализ и молишься, чтобы упало меньше семи раз.
Во-вторых, вы про IDE из 96 года просто для примера или из личного опыта? Потому что в конце 90-х я писал на JBuilder, сейчас на Eclipse, и по сути писал одно и тоже — J2EE. И нормально писалось, с автодополнениями. Я прикинул — сейчас памяти в моем компе примерно в 50-100 раз больше, и процессор по флопсам наверно на столько же мощней, но у меня стойкое ощущение, что Eclipse выбешивает меня своими тормозами побольше, чем тот JBuilder.
Поэтому возрастание удобства работы разработчика со временем из-за НТП — это иллюзия. К каждому мощному новому железу в довесок идет груз «мощного» софта который нивелирует все достижения интелловских инженеров.
Основные программы и IDE 20 лет назад работали примерно с той же скоростью и отзывчивостью, что и сейчас (по ощущениям), а до динамики первого quake'a ни один современный шутер и близко не подходит.
Чтобы написать простой сервлет 20 лет назад надо было P-II 266 с 64Mb RAM. Сейчас для этой же самой задачи надо Core i-5 с 6Gb RAM. Где логика?
Потому что он от меня ускользает.
Чтобы написать простой сервлет 20 лет назад надо было P-II 266 с 64Mb RAM. Сейчас для этой же самой задачи надо Core i-5 с 6Gb RAM.
вы утверждаете, что 20 лет назад можно было написать простой сервлет с P-II 266 с 64Mb RAM, а сейчас нельзя взять P-II 266 с 64Mb RAM и написать простой сервлет? если да, то почему нельзя?
Откуда смогут взяться «низакая латентность» и «высокая пропускная способность»?
Вы же в курсе, что рабочее время программиста стоит дороже этих гигабайтов памяти.
Можно еще попробовать поразвлекаться на тему, сколько времени теряют проектировщики с зарплатой 100 килорублей, ПМ-ы с зарплатой 100-150 килорублей, ГИПы с зарплатой 150-250 килорублей, и ГАПы с зарплатой в 300-500 килорублей в месяц в не очень крутых строительных компаниях одной только России в сравнении с тем, сколько денег сэкономлено на рабочем времени программистов.
Поверьте мне, даже самые дорогие программисты Земли будут нервно курить в сторонке. Ибо на одного «самого дорогого» программиста приходятся тысячи проектировщиков, сотни ПМ-ов и десятки ГИПов и ГАПов.
У меня там тег <сарказм> не вставился из-за перегрузки процессора в процессе написания комментария :) Ваши бы слова да богу программистов в уши. Вот сижу черчу в 2012 автокаде и слушаю музычку в медиаплеере, все летает, но тот же хабр могу просматривать исключительно только в мобильной версии, иначе, судя по звукам вентилятора, какой-то майнер запускается. Зато две вкладки мобильного хабра в файрфоксе съели 500 МБ, а 4 файла проектов в автокаде всего 200 МБ.
Причем по функционалу отличий 2006 от 2012 я особо не вижу, кроме более современного интерфейса (может это мне не приходиться пользоваться какими-то навороченными библиотеками). В старой версии работаю как на фортепиано, все отзывчиво. В новой — может и призадуматься.
Мудрые хранят как зеницу ока 6 версию, хотя лет десять уже выпуcкаются новые крутые версии Lingvo
Проблема с совместимостью, когда каждый проектировщик, желая проверить новые фишечки, ставит новый софт сразу после выхода в релиз и так и продолжает им пользоваться. Вот поэтому внутри фирмы все перешли на 2012, а для работы с особо продвинутыми пользователями с 2018ым приходится использовать конвертер. А смежники присылают файлы, сделанные с использованием всяких надстроек типа СПДС и начинаются проблемы с открытием, корректным отображением и редактированием.
Да кстати, 2012 лицензионный, через сервер лицензий. Дома Нанокад условно-бесплатный, но фирма почему то не хочет экономить деньги.
Кстати, 2006-ой автокад запускался мгновенно, т.к. был нативным приложением, а потом автодески подсели на .net.
Рабочее время программиста оплачивает разработчик софта, а ваше рабочее время — ваш работодатель. Экономия миллиона вашему работодателю за счёт скорости софта никак не отразится на кошельке разработчика софта. К сожалению. Надеюсь, появится платежеспособный спрос, тогда и предложение подтянется.
Тот же AutoDesk не сможет что-то принципиально переписать
Помню я… чертил я в автокаде кое что в 1993-м году. Там уже были макросы на Лиспе, динамические блоки и примерно весь функционал, который нужен в реальной жизни большинству проектировщиков. Я думаю, что если сейчас запустить его на современной железке в эмуляторе — летать будет круче прежнего. И памяти будет кушать что-нибудь типа 4 мегабайт, вместе с эмулятором… А вот чтобы автокад со всем своим высокоэффективным легаси из времен 286-х процессоров летал не слишком быстро и тормозил на 8 гигабайтах памяти — вот для этого разработчикам пришлось серьезно попотеть…
Выкиньте все те ракушки «3-дешности», «анимированности» и «реалистичности», что налипли на борта корабля под названьем ПО, и он понесется по волнам, как смазанная салом молния.
Полутени и закругленности это же просто картинки, они вообще любыми могут быть, а анимации плавно работали еще в самом начале 2000ых.
То есть можно сделать плавный красивый UI с анимациями поверх простого rapsberry PI если заморочится.
Да, сейчас сильно увеличилась плотность пикселей, по сравнению с началом 2000ых, но блин и производительность железа ушла далеко вперед.
Тормозят на самом деле абстракции, которые имеют далеко не нулевую стоимость во время исполнения.
это же просто картинки
Нет, это зачастую именно расчет теней. Это быстрее делается, настраивается, проще поддерживается. Но медленнее работает, да.
а анимации плавно работали еще в самом начале 2000ых
Это не так, я помню как тормозили фреймворки с красивостями по сравнению с нативным MFC.
To PKav: меня тоже это беспокоит. Но ничего сделать нельзя: если вы станете заставлять своих разработчиков делать «по-вашему», ваши работодатели вас заменят на более покладистого «индуса» — выпускать продукт надо быстро, а чтобы он работал быстро — не надо. Ничего личного, просто бизнес.
А вот во всякой веб-разработке и сервисах проще купить и воткнуть ещё один блейд-центр в серверную стойку, чем заставить программистов писать код руками.
Сам стараюсь не использовать библиотеки и писать код инициализации и обмена данными с внешними устройствами сам, оптимизируя всё с учетом архитектуры микроконтроллера (прерывания, DMA). И если вдруг мне доведется когда-то руководить программистами, буду заставлять их делать так же.
Ну есть ардуинка с библиотечками, есть еще Rust Embedded Workgroup, которые тоже пилят наборы библиотечек под контроллеры.
Так что так или иначе библиотеки проникают в embedded, но не вижу в этом ничего ужасного до тех пор, пока итоговые прошивки будут полностью соответствовать требованиям.
Хотя разок влетел в ситуацию, где надо было быстро дёргать пинами, тут-то и выяснилось, что digitalWrite — это целых ~14 мкс, а записать напрямую в порт ручками — всего-то 6 мкс.
Таких приколов по чуть-чуть на каждый слой, и вот уже всё лагает.
Пока рецепт такой.
Например, при перетаскивании элементов на экране пользователи воспринимают задержки всего в ~2 мс.
О каких задержках речь? Чтобы задержки в 2 мс хоть как-то влияли на то, что воспринимает пользователь, нужно чтобы дисплей работал на частоте 500 Hz. Чего я не понимаю?
Медленный софт