Pull to refresh

Comments 66

Лаги софта раздражают еще, помимо очевидного. описанного в статье и тем, что не дают обратной связи на действие пользователю. Скажем, если я щелкнул выключателем — я заведомо знаю, что я включил, ну, скажем, старый ламповый телевизор и жду «лаг» в виде его прогрева, так же могут быть иные средства обратной связи — индикаторы включения, шум устройства. А когда я кликаю по ярлыку, и ничего не происходит — сижу и думаю: то ли я не кликнул, то ли висит система, то ли программа «раздумывает» перед запуском, то ли что-то еще произошло. И это бесит.
А вот за лаги мобильных устройств типа «скролил экран, он тупит, нажал на экранную кнопку, но экран сдвинулся дальше, и в области нажатия оказалась совсем другая кнопка» создателей этих устройств надо вешать на фонарях. Особенно «весело» с такими закидонами серфить по инету без адблока.
Вы еще не пытались читать уникальный контент на сайтах, увешанных выскакивающими баннерами, половина который появляется при нажатии чего-либо на сайте. Эти сайты виснут даже на iphone x моего знакомого, не говоря уже про мой j330f
Ладно скролил, яндекс-телепрограмма своей рекламой сдвигает страницу после загрузки (и не только она) и если кликнул, то оно съехало и кликнулось не туда.
Статья чересчур умная, как мне кажется. Наверное, львиная часть тормозов софта из-за того, что для решения какой-то задачи зачастую подключается куча библиотек, вместо того, чтобы оформить все 20 строчками кода.
Даже эффективные грамотные фреймворки дают огромный ненужный оферхед.

У мобильников основное торможение из-за нехватки памяти и множества не оптимизированных фоновых процессов.
Обычная ситуация: простенькая с виду страничка без особой функциональности подключает пару десятков JS-скриптов, и большинство из которых используется на пару процентов. Вместо того, чтобы написать те же 20 строк кастомного кода, подключается нечто огромное и стозевное, найденное в гугле, с кучей неиспользуемых наворотов на все случаи жизни.
Буквально на днях, работая над только начавшимся проектом, решил было использовать DataTables для отображения таблицы с пользователями (тем более под Laravel есть плагин-связка с DataTables). Скачал — 500kB, в минифицированном виде — 80. В итоге написал всю необходимую функциональность в 50 строках JS/jQuery (а можно было и без jQuery обойтись, но он и так используется уже).
Ладно подключается и лежит, оно инициализироваться норовит на старте, а это время и память.
Решил попробовать фреймворк Laravel. Поставил Composer, создал пустой проект. Сколько у меня исходного кода от разных вендоров в голом приложении? 38 штук! При этом у некоторых вендоров внутри куча пакетов. И кто-то может подумать что вся эта куча кода может быстро работать на сервере?
Простая страница с доступом к БД в Laravel подключает ~350 файлов (это один запрос к серверу). Проверял через get_included_files().
Только это одно означает, что 350 раз вызывается отдельно написанная на PHP функция для подключения классов по PSR. Это при том, что PHP и сам умеет подключать нужные файлы не вызывая никаких функций на PHP, но это не соответствует PSR, поэтому никем не используется.
Вообще-то composer это кэширует, в /vendor/composer
Беда в том, что все эти слои абстракции, создаваемые различными фреймворками, прослойками и билиотеками никак не оптимизируются при сборке. По хорошему, все абстракции должны существовать только на бумаге, а при компиляции «схлопываться» в нативно исполняемый код. В реальности же каждый из слоев абстракции добавляет инициализацию кучи всего, что в вашем проекте не используется, многократное копирование данных, проверку входных параметров (на каждом слое заново!) и т.п. Плюс избыточное неуправляемое разрастание функциональности, которая нужна только 5% пользователей, но раз уж кому-то нужна, то без нее никак не обойтись.
В итоге те решения, которые срабатывали мгновенно в TurboVision 25 лет назад на 486 ныне неспешно по 1-2 секунды реагируют на нажатия мыши.
не скажу про разрастание функциональности, но вот про постоянные проверки входных параметров и копирование данных на границах абстракций — прямо ужас.
Я недавно ходил к другу отца, у него 98 винда и 386. Ох и летает она! В общем я часа полтора просто лазал по тому компу, тыкая везде и даже два раза разложил косынку. Я ещё клавишу/кнопку не отпустил, а уже все открылось. Я уж и не помню когда такое видел последний раз. Это я такое ощущение получил при том, что дома у меня комп с четырьмя ядрами, 2.8ггц, 16 гб оперативки и отключенным свопом. А ноутбук мой с двумя гигами оперативки вообще от трупа малоотличим (спасибо дебиан, десятка на нем вообще толком не работала).

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, запускающих проекты на миллионы строк. Речь про веб-сайтики, приложения на андроид. И когда они дико тормозят, то нужно понимать откуда такие задержки.
Во-первых, не понимаю, как понятие «интерактивная система» или ее основные концепции изменились за 20 лет, и почему важно, что оно на первом месте в списке литературы.

Во-вторых, вы про 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. Где логика?
а что не дает сейчас писать простые сервлеты на P-II 266 с 64Mb RAM?
В вашем вопросе есть какой-то смысл?
Потому что он от меня ускользает.
Чтобы написать простой сервлет 20 лет назад надо было P-II 266 с 64Mb RAM. Сейчас для этой же самой задачи надо Core i-5 с 6Gb RAM.

вы утверждаете, что 20 лет назад можно было написать простой сервлет с P-II 266 с 64Mb RAM, а сейчас нельзя взять P-II 266 с 64Mb RAM и написать простой сервлет? если да, то почему нельзя?
Можно взять и написать
В чем вопрос?
Чтобы написать простой сервлет 20 лет назад надо было P-II 266 с 64Mb RAM. Сейчас для этой же самой задачи надо Core i-5 с 6Gb RAM. Где логика?

к чему это?
Вы не видите логики? Я тоже. Смотрите, специально же даже написал: Где логика?
Я рад, что мы мыслим в одном направлении.
Всего хорошего.
вопрос был другой, но ладно
и вам всего хорошего
О чем в принципе можно говорить, если вот эта конкретная страница, на которой на данный момент есть аж целых 33 килобайта текста (включая пробелы и знаки препинания), занимает в памяти компьютера 160 с мелочью мегабайт? Не считая гигабайта, который занимает остальной веб браузер и двух гигабайт, которые заняты другими вкладками в этом веб браузере?
Откуда смогут взяться «низакая латентность» и «высокая пропускная способность»?

Вы же в курсе, что рабочее время программиста стоит дороже этих гигабайтов памяти.

А мое рабочее время, когда у меня из-за установленного автокада запущено 4 хромиум хост экзекьютабл, которые жрут у меня на рабочем ноуте 10-20% процессора? Это при не запущенном автокаде! А если запустить автокад не прибив хром, или хотябы вкладки с хабром и новостными лентами, начинается своппинг, несмотря на установленные максимальные для моего ноута 16 гигов памяти… И все встает колом. И банальный альт-таб из автокада в аутлук — развлечение на десятки секунд.
Можно еще попробовать поразвлекаться на тему, сколько времени теряют проектировщики с зарплатой 100 килорублей, ПМ-ы с зарплатой 100-150 килорублей, ГИПы с зарплатой 150-250 килорублей, и ГАПы с зарплатой в 300-500 килорублей в месяц в не очень крутых строительных компаниях одной только России в сравнении с тем, сколько денег сэкономлено на рабочем времени программистов.
Поверьте мне, даже самые дорогие программисты Земли будут нервно курить в сторонке. Ибо на одного «самого дорогого» программиста приходятся тысячи проектировщиков, сотни ПМ-ов и десятки ГИПов и ГАПов.

У меня там тег <сарказм> не вставился из-за перегрузки процессора в процессе написания комментария :) Ваши бы слова да богу программистов в уши. Вот сижу черчу в 2012 автокаде и слушаю музычку в медиаплеере, все летает, но тот же хабр могу просматривать исключительно только в мобильной версии, иначе, судя по звукам вентилятора, какой-то майнер запускается. Зато две вкладки мобильного хабра в файрфоксе съели 500 МБ, а 4 файла проектов в автокаде всего 200 МБ.

Занятно. Мне иногда приходиться использовать Автокад как чертилку с некоторыми «плюшками». Пришлось потратить время, чтобы на торрентах отыскать ACAD 2006. Установлен параллельно с более «новым» 2012. По собственному опыту и по описаниям на форумах ACAD 2006 MD — последняя версия, которая запускалась мгновенно с холодного старта даже на древнем компьютере. Сейчас 2012 версия запускается 23 сек на стационарном i7 с 16 Гб ОЗУ (про более новые версии ACAD я вообще молчу).
Причем по функционалу отличий 2006 от 2012 я особо не вижу, кроме более современного интерфейса (может это мне не приходиться пользоваться какими-то навороченными библиотеками). В старой версии работаю как на фортепиано, все отзывчиво. В новой — может и призадуматься.
Та же хрень с ABBYY Lingvo
Мудрые хранят как зеницу ока 6 версию, хотя лет десять уже выпуcкаются новые крутые версии Lingvo

Проблема с совместимостью, когда каждый проектировщик, желая проверить новые фишечки, ставит новый софт сразу после выхода в релиз и так и продолжает им пользоваться. Вот поэтому внутри фирмы все перешли на 2012, а для работы с особо продвинутыми пользователями с 2018ым приходится использовать конвертер. А смежники присылают файлы, сделанные с использованием всяких надстроек типа СПДС и начинаются проблемы с открытием, корректным отображением и редактированием.
Да кстати, 2012 лицензионный, через сервер лицензий. Дома Нанокад условно-бесплатный, но фирма почему то не хочет экономить деньги.

Кстати, 2006-ой автокад запускался мгновенно, т.к. был нативным приложением, а потом автодески подсели на .net.

Рабочее время программиста оплачивает разработчик софта, а ваше рабочее время — ваш работодатель. Экономия миллиона вашему работодателю за счёт скорости софта никак не отразится на кошельке разработчика софта. К сожалению. Надеюсь, появится платежеспособный спрос, тогда и предложение подтянется.

UFO just landed and posted this here
И это всё равно не поможет. Потому что тормозит огромный слой legacy. Тот же AutoDesk не сможет что-то принципиально переписать, не отказавшись от столетних фич. Да и зачём ему что-то сильно переписывать, если и так купят. А перейти на другую, быструю программу, но несовместимую, пользователи не смогут.
Тот же AutoDesk не сможет что-то принципиально переписать

Помню я… чертил я в автокаде кое что в 1993-м году. Там уже были макросы на Лиспе, динамические блоки и примерно весь функционал, который нужен в реальной жизни большинству проектировщиков. Я думаю, что если сейчас запустить его на современной железке в эмуляторе — летать будет круче прежнего. И памяти будет кушать что-нибудь типа 4 мегабайт, вместе с эмулятором… А вот чтобы автокад со всем своим высокоэффективным легаси из времен 286-х процессоров летал не слишком быстро и тормозил на 8 гигабайтах памяти — вот для этого разработчикам пришлось серьезно попотеть…
Фичи-то добавляются. Приложение под 93-й автокад как-то дожило до современного, но приложение с последнего не запустится на 93-м, а значит, такой автокад не поставишь.
Надо все же признать что хром ест cpu только при активной работе. Ну или ноут на селероне, но вы говорите про автокад, поэтому откидываю этот вариант.
Ну и да, дурацкий вопрос, но куда ушли 159967 килобайт памяти? На странице же всего текста было 33 килобайта! Ну ладно, еще 33 килобайта на тэги и разметку. Куда 159934 килобайта израсходовали? Я не смогу поверить, что это все съел подгруженный редактор комментариев. Я такого класса и уровня редактор (с подсветкой синтаксиса!!!) писал. Он весь был меньше 12 килобайт в скомпилированном виде (ради чего, собственно, и затевался, чтобы в доступных на тот момент 64 кБ оперативки поместить больше 32 кБ редактируемого текста...).
Распаршенный DOM, виртуальная машина с сэндбоксом…
Ну и да, дурацкий вопрос, но куда ушли 159967 килобайт памяти?
Напомнило чо та...

Картинки, файл шрифта, JS, CSS, и т.д. Тут есть много чего ещё до того, как оно превратится в объекты представляющие это в оперативной памяти.
Вы видео учитывали? Я понимаю, что в норме это были бы десятки и сотни килобайт на один плейсхолдер незагруженного видео, но ведь пара порядков там вполне может потеряться.
UFO just landed and posted this here
Вообще-то, лаг тормозов автомобиля как раз в секунду считается.

Пользователи замечают, но их же не спрашивают. Знаю человека принципиально сидящего на айфонах из-за меньших лагов, для него это важно.

А так всё хорошо начиналось. Вроде и проблему хорошо выделили, и причину её возникновения описали хорошо. А в конце всё равно «мышки станьте ёжиками» в смысле «давайте просто возьмём, и станем делать лучше». При этом внятных соображений, как можно «делать лучше» не увеличивая при этом в разы бюджет и время работы, естественно не предлагается.
Программы тормозят из-за любви (разработчиков-дизайнеров и пользователей) к «ми-ми-ми-шности». Все эти тени-полутени, закругленности, все эти анимации и т.п. Особенно к «реалистичности» всех этих наворотов, как будто реальность имеет отношение к виртуальному миру ПО. Я говорю о реальности тени, реальности эффекта нажатия на кнопку и т.п. хрени, которая никакой пользы не несет никому. Именно благодаря отсутствию всего этого в интерфейсе командной строки эти программы и летают.
Выкиньте все те ракушки «3-дешности», «анимированности» и «реалистичности», что налипли на борта корабля под названьем ПО, и он понесется по волнам, как смазанная салом молния.
Мимишность продаётся, чуть меньший лаг — нет (в том числе разработчиками заказчику). Делают что приносит больше профита по отношению к затратам.

Полутени и закругленности это же просто картинки, они вообще любыми могут быть, а анимации плавно работали еще в самом начале 2000ых.
То есть можно сделать плавный красивый UI с анимациями поверх простого rapsberry PI если заморочится.
Да, сейчас сильно увеличилась плотность пикселей, по сравнению с началом 2000ых, но блин и производительность железа ушла далеко вперед.
Тормозят на самом деле абстракции, которые имеют далеко не нулевую стоимость во время исполнения.

это же просто картинки

Нет, это зачастую именно расчет теней. Это быстрее делается, настраивается, проще поддерживается. Но медленнее работает, да.

а анимации плавно работали еще в самом начале 2000ых

Это не так, я помню как тормозили фреймворки с красивостями по сравнению с нативным MFC.

А я помню интерфесы в игрушках. Они почему то содержали красивости, но не лагали.

Это не «просто картинки» — вы вспомните о том, что все эти округлости — это прозрачность, да многослойная, т.к. одно на другое накладывается. Возьмем курсор мышки: изначально было две BMP-хи, одна маска, другая картинка. Как только придумали тень от мышки — надо просчитывать каждый пиксел этой тени, чтобы вычислить «приглушенный цвет фона» — это сколько работы прибавилось? Помножьте это на те самые скорости движения, и выйдет, что только рисованием мышки мы пожираем столько же ресурсов, сколько весь интерфейс командой строки. И так на каждый чих современного интерфейса: раньше ссылка подсвечивалась при наведении курсора просто «хоп!», а теперь — с анимацией, плавненько, и погасает подсветка так же плавненько, с анимацией… Это вам не просто картинки. Кстати, для, казалось бы, простого вывода картинки используется такой слой промежуточных функций, выделения памяти и т.п. накладных ресурсов, что не так все это и просто на самом деле. Тут ведь как в автомастерской: сосед по гаражу вам гайку закрутит за 5 минут, а в сервисе — менеджер составит планчик, рассчитает стоимость, кассир примет оплату, мастер даст задание механику, механик поставит машину на подъемник, открутит гайку, мастер примет работу, передаст менеджеру, менеджер поставит галочку в компьютере и выдаст вам машинку. Вот вам и просто. Зато «сервис».
To PKav: меня тоже это беспокоит. Но ничего сделать нельзя: если вы станете заставлять своих разработчиков делать «по-вашему», ваши работодатели вас заменят на более покладистого «индуса» — выпускать продукт надо быстро, а чтобы он работал быстро — не надо. Ничего личного, просто бизнес.
Да, на самом деле, всё не так страшно в этой области. Если объяснить руководству то, что индус постепенно подведет их под замену микроконтроллера на более мощный и компания потеряет деньги на серийном производстве, то вряд ли они останутся равнодушны.

А вот во всякой веб-разработке и сервисах проще купить и воткнуть ещё один блейд-центр в серверную стойку, чем заставить программистов писать код руками.
Сделать сайт «мимишным» с точки зрения ресурсов стоит очень недорого. Если руки из нужного места растут.
А меня пугает то, что растет производительность микроконтроллеров встраиваемых систем. За 3 доллара можно купить 2-ядерный микроконтроллер с частотой 240 МГц и 8 Мб памяти. Это приводит к тому, что кривые тормозные библиотеки и фреймворки потянутся туда, и тормозить уже начнет не только компьютер и смартфон, но и погодная станция, панель управление лифтом и бортовой компьютер автомобиля.

Сам стараюсь не использовать библиотеки и писать код инициализации и обмена данными с внешними устройствами сам, оптимизируя всё с учетом архитектуры микроконтроллера (прерывания, DMA). И если вдруг мне доведется когда-то руководить программистами, буду заставлять их делать так же.

Ну есть ардуинка с библиотечками, есть еще Rust Embedded Workgroup, которые тоже пилят наборы библиотечек под контроллеры.
Так что так или иначе библиотеки проникают в embedded, но не вижу в этом ничего ужасного до тех пор, пока итоговые прошивки будут полностью соответствовать требованиям.

Ну если своя начинка у ардуины ещё туда-сюда, то вот библиотеки порой написаны так, что без слёз не взглянешь.

Хотя разок влетел в ситуацию, где надо было быстро дёргать пинами, тут-то и выяснилось, что digitalWrite — это целых ~14 мкс, а записать напрямую в порт ручками — всего-то 6 мкс.

Таких приколов по чуть-чуть на каждый слой, и вот уже всё лагает.
По сути, боян сорокалетней а то и большей давности. В конце 60-х Hewlett Packard проводила исследования по клавиатурам и системам графического ввода информации. В 70-х IBM разработала требования к отзывчивости интерфейса и даже разработала требования к соответствующей аппаратно-программной архитектуре. Достаточно поднять их результаты и просто воспользоваться вместо тогшо, чтобы пиарить огрызки — человек за 40 тысяч лет не изменился, за сорок он тем более остался тем же.
От всех задержек избавиться не выйдет, но большую часть решает мощная система на 8700k/9900k/2700x. Главное чтобы когда эта сборка станет мейнстримом появилась новая сборка которая опять на голову выше народных i5.
Пока рецепт такой.
Например, при перетаскивании элементов на экране пользователи воспринимают задержки всего в ~2 мс.

О каких задержках речь? Чтобы задержки в 2 мс хоть как-то влияли на то, что воспринимает пользователь, нужно чтобы дисплей работал на частоте 500 Hz. Чего я не понимаю?
А лучше на 1000 Hz, чтобы уверенно говорить о задержке в 2 мс, а не 3.
Sign up to leave a comment.

Articles