Моё разочарование в софте

http://tonsky.me/blog/disenchantment/
  • Перевод

Суть разработки программного обеспечения
— Нужно проделать 500 отверстий в стене, так что я сконструировал автоматическую дрель. В ней используются элегантные точные шестерни для непрерывной регулировки скорости и крутящего момента по мере необходимости.
— Отлично, у неё идеальный вес. Загрузим 500 таких дрелей в пушку, которые мы сделали, и выстрелим в стену.


Я занимаюсь программированием уже 15 лет. Но в последнее время при разработке не принято думать об эффективности, простоте и совершенстве: вплоть до того, что мне становится грустно за свою карьеру и за IT-отрасль в целом.

Для примера, современные автомобили работают, скажем, на 98% от того, что физически позволяет нынешняя конструкция двигателя. Современная архитектура использует точно рассчитанное количество материала, чтобы выполнять свою функцию и оставаться в безопасности в данных условиях. Все самолёты сошлись к оптимальному размеру/форме/нагрузке и в основном выглядят одинаково.

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений. Люди даже гордятся, насколько неэффективно работает программа, типа «зачем беспокоиться, компьютеры достаточно быстрые»:

@tveastman: Я каждый день запускаю программу на Python, она выполняется за 1,5 секунды. Я потратил шесть часов и переписал её на Rust, теперь она выполняется за 0,06 секунды. Это ускорение означает, что моё время окупится через 41 год, 24 дня :-)

Наверное, вы слышали такую мантру: «Время программиста дороже времени компьютера». Это означает, что мы тратим компьютерное время в беспрецедентных масштабах. Вы бы купили машину с расходом 100 литров на 100 километров? Как насчёт 1000 литров? С компьютерами такое происходит постоянно.

Всё невыносимо медленно


Оглянитесь вокруг: портативные компьютеры в тысячи раз мощнее тех, что привели человека на Луну. Тем не менее, каждый второй сайт не может обеспечить плавную прокрутку страницы на 60 FPS на последнем топовом MacBook Pro. Я могу комфортно играть в игры, смотреть видео 4K, но не прокручивать веб-страницы! Это нормально?

Почтовому приложению Google Inbox в браузере Chrome от той же Google, требуется 13 секунд, чтобы открыть письмо среднего размера:


Он ещё анимирует пустые белые формы вместо того, чтобы показать их содержимое, потому что это единственный способ анимировать что-то на веб-странице с приличной производительностью. Нет, не 60 FPS, а скорее «настолько быстро, насколько возможно на этой странице». С нетерпением жду, что же веб-сообщество предложит, когда дисплеи 120 Гц станут мейнстримом. Они еле справляются с 60 Гц.

Обновление Windows 10 занимает 30 минут. Что можно делать так долго? Этого времени достаточно, чтобы полностью отформатировать мой SSD-накопитель, загрузить свежий билд и установить его примерно 5 раз подряд.



Павел Фатин: Набор текста в редакторе — относительно простой процесс, поэтому даже 286 могли обеспечить довольно плавный процесс набора.

В современных текстовых редакторах задержка при наборе больше, чем в 42-летнем Emacs. Текстовые редакторы! Что может быть проще? На каждое нажатие клавиши, нужно всего лишь обновить крошечную прямоугольную область на экране, а современные текстовые редакторы не могут сделать это за 16 мс. А это много времени. МНОГО. 3D-игра заполняет экран сотнями тысяч (!!!) полигонов за те же 16 мс, а также обрабатывает ввод, пересчитывает мир и динамически загружает/выгружает ресурсы. Как так?

Тенденция такова, что софт вовсе не становится быстрее и функциональнее. Мы получаем более быстрое оборудование, на котором софт с теми же функциями ворочается медленнее, чем раньше. Всё работает намного медленнее максимальной скорости. Никогда не задумывались, почему ваш телефон загружается от 30 до 60 секунд? Почему он не может загрузиться, скажем, за одну секунду? Здесь нет никаких физических ограничений. Лично мне бы такое понравилось. Хочется, чтобы разработчики достигли предела, используя каждый бит для производительности.

Всё ОГРОМНОЕ


И ещё это раздутие. Веб-приложения могут открываться в десять раз быстрее, если просто заблокировать рекламу. Google умоляет всех прекратить тормоза с помощью инициативы AMP — технического решения, для которого не нужны какие-либо технологии, просто немного здравого смысла. Если удалить раздувание, интернет станет работать на сумасшедшей скорости. Неужели это сложно понять?

Система Android без приложений занимает почти 6 ГБ. Просто задумайтесь на секунду, насколько неприлично огромное это число. Что там, фильмы в HD-качестве? Думаю, в основном код: ядро, драйверы. Ещё какие-то ресурсы, конечно, но они не могут быть такими большими. Сколько же драйверов вам нужно для телефона?



Windows 95 занимала 30 МБ. Сегодня у нас есть веб-страницы тяжелее, чем эта ОС! Windows 10 уже 4 ГБ, то есть в 133 раза больше. Но разве она в 133 раза лучше? Я имею в виду, функционально они практически одинаковы. Да, у нас появилась Кортана, но я сомневаюсь, что она весит 3970 МБ. Но это Windows 10, неужели Android должен быть ещё в полтора раза больше?

Приложение клавиатуры Google как ни в чём не бывало съедает 150 МБ. Эта программа рисует 30 клавиш на экране — она правда в пять раз сложнее, чем вся Windows 95? Приложение Google app, в основном, просто пакет для Google Web Search, занимает 350 МБ! Сервисы Google Play, которыми я не пользуюсь (я не покупаю там книги, музыку или видео) — 300 МБ, которые просто сидят здесь и которые нельзя удалить.



После установки всех необходимых приложений (социальные сети, чаты, карты, такси, банки и т. д.) на телефоне остался всего 1 гигабайт для фотографий. И это вообще без игр и музыки! Помните времена, когда ОС, приложения и все ваши данные помещались на дискету?

Ваша программа для заметок наверняка написана в Electron и, таким образом, поставляется с драйвером для контроллера Xbox 360, умеет показывать 3D-графику, воспроизводить аудио и фотографировать с помощью веб-камеры.



Простой текстовый чат всегда славился скоростью и малым потреблением памяти. Так что Slack — это пример очень ресурсоёмкого приложения. Я имею в виду, что чат и текстовый редактор — это самые базовые вещи, они должны потреблять меньше всего ресурсов. Добро пожаловать в 2018 год.

Вы можете сказать, что они хотя бы работают. Но увеличение размера — не значит улучшение. Это значит, что кто-то потерял контроль. Мы больше не знаем, что происходит. Увеличение размера — это повышение сложности, снижение производительности и надёжности. Это ненормально и не должно считаться нормой. На раздутый размер нужно сразу обращать внимание — и держаться от них подальше.

Всё гниёт


Android-телефон на 16 ГБ был прекрасен три года назад. Сегодня под Android 8.1 он еле работает, потому что каждое приложение увеличилось минимум вдвое без видимых причин. Дополнительных функций нет. Они не стали быстрее и внешний вид не изменился. Они просто… раздулись?

iPhone 4s вышел с iOS 5, но едва может работать под управлением iOS 9. И это не потому, что iOS 9 намного лучше — в основном, система не изменилась. Но новое оборудование быстрее, поэтому они сделали программное обеспечение медленнее. Не волнуйтесь — вы получили захватывающие новые возможности, например… работа тех же приложений с той же скоростью! Не знаю.

iOS 11 прекратила поддержку 32-разрядных приложений. Это значит, что если разработчик не готов вернуться и обновить приложение, скорее всего, вы не увидите снова эту отличную программу.

@jckarter: Программу DOS можно заставить работать без изменений практически на любом компьютере, сделанном после 80-х годов. Приложение JavaScript может прекратить работу из-за завтрашнего обновления Chrome.

Сегодняшние веб-страницы не будут работать в любом браузере через 10 лет (а может и раньше).

«Нужно бежать со всех ног, чтобы только остаться на том же месте». Но смысл? Я могу постоянно покупать новые телефоны и ноутбуки, как все, но делать это лишь ради того, чтобы иметь возможность запускать все те же приложения, которые стали только медленнее?

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

Хуже — значит лучше


Сейчас никто ничего не понимает. И не хочет понимать. Мы просто выпускаем полусырую ерунду, надеемся на лучшее и называем это «здравым смыслом для стартапа».

Веб-страницы просят обновиться, если что-то пошло не так. У кого есть время, чтобы найти причину неполадки?



Любое веб-приложение выдаёт постоянный поток «случайных» ошибок JS, даже на совместимых браузерах.

Вся архитектура баз данных веб/SQL построена на предпосылке (даже надежде), что никто не изменит данные, пока вы смотрите на открытую веб-страницу.

Большинство приложений для совместной работы сделали «как смогли», там масса типичных сценариев, когда они теряют данные. Видели диалог «Какую версию сохранить?» Сегодня планка так низка, что пользователи рады даже этому вопросу.



И нет, в моём мире не является нормальным приложение, которое говорит: «Я уничтожу часть твоей работы, только выбери какую».

Linux намеренно убивает случайные процессы. И всё же это самая популярная серверная ОС.

У меня каждое устройство регулярно выходит из строя так или иначе. Время от времени монитор Dell нужно аппаратно перезагружать, потому что в нём есть софт. AirDrop? Вам повезёт, если он обнаружит устройство, иначе что делать? Bluetooth? Спецификации настолько сложны, что устройства не будут устанавливать связь друг с другом, а периодические перезагрузки — оптимальный вариант.



И я даже не упоминаю об Интернете вещей. Это настолько за гранью разумного, что даже нечего добавить.

Я хочу гордиться своей работой. Я хочу делать рабочие, стабильные вещи. Для этого нужно понять, что конкретно мы разрабатываем, внутри и снаружи, а это невозможно сделать в раздутых, чрезмерно усложнённых системах.

В программировании такой же хаос


Кажется, что никто больше не заинтересован в качественных, быстрых, эффективных, долговечных, основательных решениях. Даже если давно известны эффективные решения, мы по-прежнему боремся с теми же проблемами: управление пакетами, системы сборки, компиляторы, конструкция языка, IDE.

Системы сборки по своей сути ненадёжны и периодически требуют полной очистки, хотя у них есть вся информация для инвалидации. Ничто не мешает сделать процесс сборки надёжным, предсказуемым и на 100% воспроизводимым. Просто никто не думает, что это важно. NPM уже много лет находится в состоянии «иногда работает».

@przemyslawdabek: Кажется, что rm-rf node_modules является неотъемлемой частью рабочего процесса в проектах Node.js/JavaScript.

А время сборки? Никто не считает проблемой, что компилятор работает минуты или даже часы. А как же «время программиста дороже»? Почти все компиляторы, пре- и постпроцессоры значительно, иногда катастрофически увеличивают время сборки, не обеспечивая пропорционально существенных преимуществ.



Вы ожидаете, что программисты будут принимать в основном рациональные решения, но иногда они делают прямо противоположное. Например, выбирая Hadoop даже если он медленнее, чем выполнение той же задачи на одном десктопном компьютере.

Машинное обучение и ИИ отбросили программное обеспечение к гаданию на кофейной гуще во времена, когда большинство компьютеров даже не были достаточно надёжными.

@rakhim: Когда приложение или сервис говорит «под управлением ИИ» или «на основе машинного обучения», я читаю это как «ненадёжное, непредсказуемое поведение, которое не поддаётся объяснению». Я держусь подальше от «ИИ», потому что хочу от компьютеров противоположного: надёжности, предсказуемости и логики.

Мы засунули виртуальные машины в Linux, а затем засунули Docker в виртуальные машины, просто потому что никто не смог разобраться с бардаком, который производят большинство программ, языков и их окружений. Мы накрываем дерьмо одеялами, чтобы не убирать его. Например, «единый бинарник» остаётся ОГРОМНЫМ преимуществом Go. Нет бардака == успех.


Окружающая среда Python настолько загрязнилась, что мой ноутбук объявили зоной экологической катастрофы.
Примечание. Агентство по защите окружающей среды Python хотело залить его цементом и захоронить с картинкой на входе — предупреждением для будущих цивилизаций об опасности использовать sudo для установки случайных пакетов


А зависимости? Люди бездумно ставят переусложнённые «полные пакеты» для простейших проблем, не думая о последствиях. Из этих зависимостей растут новые. В конечном итоге вы получаете дерево, которое является чем-то средним между фильмом ужасов (огромное и полное конфликтов) и комедией (нет причин, по которым мы добавили сюда эти пакеты, но вот они):



Программы не могут работать несколько лет без перезагрузки. Иногда даже несколько дней — это слишком. Происходят случайные глюки, и никто не знает почему.

Что ещё хуже, ни у кого нет времени остановиться и выяснить, что произошло. Зачем беспокоиться, если всегда есть другой выход. Поднять новый инстанс AWS. Перезапустить процесс. Удалить и восстановить базу данных. Написать скрипт, который будет перезапускать ваше сломанное приложение каждые 20 минут. Включить одни и те же ресурсы несколько раз: тяп-ляп — и в продакшн. Двигайся быстро, не трать время на исправление ошибок.

Это не инженерная работа. Это просто ленивое программирование. Инженерная работа предполагает глубокое понимание производительности, структуры и ограничений того, что вы создаёте. Лепить халтуру из некачественного материала — совершенно противоположное занятие. Чтобы развиваться, мы должны понимать, что и зачем мы делаем.

Мы застряли


Таким образом, всё это просто куча едва работающего кода, добавленного поверх ранее написанного едва работающего кода. Он продолжает расти в размерах и сложности, уменьшая шансы на изменения.

Чтобы иметь здоровую экосистему, необходимо вернуться. Необходимо иногда выбрасывать хлам и заменять его лучшими альтернативами.



Но у кого есть на это время? Новые ядра ОС не выходили сколько, 25 лет? Это сейчас стало слишком сложным, чтобы просто взять и переписать. В браузерах накопилось столько пограничных ситуаций и исторических прецедентов, что никто не осмелится писать движок с нуля.

Сегодняшнее определение прогресса — или подбросить топлива:

@sahrizv: 2014 — нужно внедрить микросервисы для решения проблем с монолитами.
2016 — нужно внедрить Docker, чтобы решить проблемы с микросервисами.
2018 — нужно внедрить Kubernetes, чтобы решить проблемы с Docker.

или изобретать велосипед:

@dr_c0d3: 2000: напишите 100 строк XML, чтобы «декларативно» настроить сервлеты и EJB.
2018: напишите 100 строк YAML, чтобы «декларативно» настроить микросервисы.
В XML были хотя бы схемы…

Мы застряли, и никто нас не спасёт.

Бизнесу всё равно


Пользователям тоже. Они выучились принимать то, что мы делаем. Мы (инженеры) говорим, что каждое приложение для Android занимает 350 МБ? Хорошо, они будут с этим жить. Мы говорим, что не можем обеспечить плавную прокрутку? Окей, они свыкнутся с телефоном, который подтормаживает. Мы говорим: «Если не работает, перезагрузитесь»? Они перезагрузятся. Ведь у них нет выбора.

Конкуренции тоже нет. Все строят одни и те же медленные, раздутые, ненадёжные продукты. Случайный скачок вперёд по качеству даёт конкурентное преимущество (iPhone/iOS против других смартфонов, Chrome против других браузеров) и заставляет всех перегруппироваться, но ненадолго.

Наша миссия как инженеров — показать миру потрясающие возможности современных компьютеров с точки зрения производительности, надёжности, качества и удобства использования. Если нам не всё равно, люди потянутся. И никто кроме нас не покажет им, что такое возможно. Если только нам не наплевать.

Не всё так плохо


Иногда на пасмурном небосводе просвечивают лучики надежды.

Работа Мартина Томпсона (LMAX Disruptor, SBE, Aeron) впечатляет, она освежающе проста и эффективна.

Редактор Xi Рафа Левиена, кажется, построен на правильных принципах.

Джонатан Блоу для своей игры разработал язык компилирования, который компилирует 500 000 строк в секунду на ноутбуке. Это холодная компиляция, никакого промежуточного кэширования, никаких инкрементальных билдов.

Не нужно быть гением, чтобы писать быстрые программы. Здесь нет какой-то магии. Единственное, что требуется, — это не строить софт на базе огромной кучи дерьма, которую поставляют современные инструменты.

Манифест лучшего мира


Я хочу видеть прогресс. Я хочу перемен. Чтобы современное программное обеспечение совершенствовалось, а не стояло на месте. Я не желаю заново изобретать одно и то же, каждый раз выпуская всё более медленный и раздутый продукт. Я хочу во что-то верить — в достойную цель, в будущее, которое лучше, чем то, что мы имеем сегодня, и чтобы появилось сообщество инженеров, которые разделяют это видение.

Что мы имеем сегодня — это не прогресс. Мы едва достигаем бизнес-целей с этими плохими инструментами. Мы застряли в локальном оптимуме, и никто не хочет двигаться. Это даже не хорошее место, оно раздутое и неэффективное. Мы просто как-то привыкли к нему.

Поэтому я хочу заявить: нынешняя ситуация — полное дерьмо. Как инженеры, мы можем и должны, и сделаем лучше. У нас могут быть лучшие инструменты, мы можем создавать лучшие приложения, более быстрые, предсказуемые, более надёжные, использующие меньше ресурсов (на порядки меньше!). Мы должны глубоко понять, что мы делаем и почему. Мы должны выпускать продукты надёжно, предсказуемо, с самым высоким качеством. Мы можем и должны гордиться нашей работой. Не просто «учитывая то, что у нас было...» — никаких оговорок!

Надеюсь, я не одинок. Надеюсь, что есть люди, которые хотят того же. Я буду рад, если мы хотя бы начнём говорить о том, насколько абсурдно нелепа нынешняя ситуация в индустрии программного обеспечения. А потом, возможно, придумаем, как выбраться из неё.
Поделиться публикацией
Комментарии 2432
    +39
    Это всё, конечно, правильно, но, мне интересно, готов ли автор (да, я вижу что это перевод) платить вместо условной тысячи долларов за новый телефон — платить 50 000? И тогда действительно расширят штат разработчиков, чтобы у них было время писать ядро системы отдельно под каждый телефон. А ещё придётся платить за каждый веб-сайт, потому что разрабатывать каждый раз всё с нуля, без использования библиотек и фреймворков — будет очень и очень дорого. Вот поэтому, там где оно надо (космос, например, или военка) — там и оптимизируют. А в реальном мире пользователю важнее получить приложение за 1$ которое будет работать и на его телефоне, и на планшете, и даже на телевизоре…
      +8
      Всё хорошо в меру. Только что попробовали открыть XML файл в пару сотен метров (не спрашивайте зачем) в 17 VisualStudio под десяткой. На относительно свежем компе с 4 пнём (хз какой именно) и 16ГБ оперативки. Через 15 минут грохнули не дождавшись его выхода из медитации.
        +4
        А в FARе за сколько откроет?
          +19
          Мгновенно, он умеет обрабатывать кусочками из произвольного места. Только colorer плагин будет в фоне с начала расцветку считать.
            –10

            'кусочками' научно называется memory mapped files :)

              +1
              К словам придираетесь
                +1
                Я не придираюсь — даю детали для потенциально заинтересовавшихся реализацией.
                +4
                Мне кажется, memory mapped files тут мало при чём. Речь о том, что некоторые редакторы способны отображать файл, лишь распарсив его целиком, а некоторым достаточно распарсивания некоторых определённых частей (в т.ч. той, которая должна быть отображена в данный момент, т.к. находится в видимой на экране части документа). Memory mapped files тут в принципе можно применить, но, по-моему, не обязательно, обычных lseek/read вполне достаточно, разница скорее в алгоритмах, а не в lseek+read vs. mmap.
                  +1
                  Memory mapped files тут не просто можно, а обязательно ибо иначе будет больше вероятность лагов ;)
                    +1
                    Мне кажется, или в случае, если весь файл влезает в RAM (точнее даже не так, если все данные, необходимые парсеру/просмотрщику влезают в RAM), то это совершенно лишнее? Исходя из определения
                      +2
                      Не лишнее, memory mapped files позволяют убрать лишнюю прослойку и сразу использовать данные из файлового кэша системы. При использовании обычного подхода получится, что система в любом случае откроет файл и он в любом случае будет в кеше, но в память приложения данные придётся копировать. и для sasha1024 тоже.
                        0
                        Я так понимаю, в кэше будет не обязательно весь файл, а может быть часть файла (если он большой).
                        А что значит «но в память приложения данные придётся копировать»?
                        Upd.: А, всё, я кажется, понял. При read происходит перенос данных в уже выделенную пользователем память. При этом эта память уже контроллируется приложением, т.е. оптимизировать это каким-то ре'map'ингом страниц (или как там ОС это делать может) не выйдет.
                          0
                          Агу, именно так. Кроме того остаётся пусть и небольшой но оверхед на работу самих API файловой системой, а тут для приложения сразу доступен уже очищенный от всего связанного с ФС кусок памяти содержащий данные файла.
                            0
                            Ну, оверхед на работу с файловой системой будет в любом случае — разве нет?
                              0
                              Этот оверхед конечно останется, но вся эта работа и так производится. Просто тут очень удобно получается, что данные уже лежат в памяти и воспринимать их как файл нет никакой необходимости.
                                0
                                Ну, на скорости это практически не сказывается.
                                  0
                                  О чём вы спорите?
                                  Far давно в Open Source — уже можно было пять раз посмотреть
                                    0
                                    Не совсем понял, как реализация Far'а что-то докажет.
                            0
                            Более того благодаря этому можно делать очень полезные вещи для многопроцессной обработки чего либо.
                              +2
                              По сути, благодаря mmap мы избегаем лишнего копирования данных из одного участка оперативной памяти в другой. Что достаточно быстрая операция. А основной затык тут не в mmap vs. lseek+read, а именно в алгоритмах, которые либо довольствуются малыми кусочками файла, либо заставляют вычитать с диска (нагрузка на диск) и распарсить (нагрузка на процессор и опять же таки оперативную память) значительный кусок файла или вообще весь файл.
                          0
                          Обосновать как-то сможете?
                            +3
                            редактор/ide отображает (при подсветке синтаксиса и прочих плюшках) не plain text (где да, memory mapping помог бы) а по сути AST дерево, которое надо где то хранить. И вот это AST во первых весит больше исходника, во вторых его еще создать надо — то есть распарсить весь исходник. vim худо бедно справляется потому что у него подсветка на регулярках, и она регулярно ломается.
                              0
                              И вот это AST во первых весит больше исходника…
                              Кстати, необязательно. Это AST может:
                              • во-первых, не содержать в себе сами строки, а лишь ссылаться на позиции в исходном файле;
                              • во-вторых, быть не полностью детализированным (т.е. условно говоря, мы распарсим первую функцию в файле-исходнике полностью на всю глубину, но если она выше екрана, то тут же забудем результат парсинга за исключением её собственно начала и конца (т.е. удалим все узлы глубже узла самой функции), а если она снова попадёт в экран — распарсим заново (т.е. детализируем этот кусочек дерева)).
                              Но, да, на практике там делают немногие, та и в любом случае всё, что выше экрана, придётся распарсить, а это время, даже если результат детально не хранить.
                              0
                              Похожий функционал был еще в некоторых DOS-приложениях (для просмотра БОЛЬШИХ изображений вроде растровых карт) а в DOS memory-mapped files не бывает. Руками можно все сделать. Сложно но можно.
                                0

                                Memory mapped files — это просто немного удобства для программиста. Под CP/M-80 (в которой ещё не было не то что mmf — банальных file handles) текстовый редактор wordstar спокойно правил файл больше размера оперативки.

                          +5
                          Не знаю, как фар, а блокнот++ открывает за <1сек.
                          Вообще по опыту там дико тормозит подсветка кода, и такая беда не только там.
                            +4
                            Ну конечно, ведь в этом случае надо разбить текст на токены, и хорошо если разработчик предусмотрел токенизацию ± экран, но ведь в сложных больших структурах где, к примеру, есть один корень и много ветвей (тот же xml), это может быть нереально, соответственно нельзя определить где находится начало, откуда можно стартовать синтаксический разбор, и соответственно корректную подсветку создать просто не выйдет.
                              0
                              Как раз в xml это проще простого. Токенов там мало и они все достаточно легко распознаются. Там не требуется делать разметку с корня, достаточно чуть отойти назад и найти начало любого токена. Проблема будет только с CDATA, но на него пофиг.
                                +1
                                Возможно, но опять же имхо зависит от структуры xml, на моём текущем проекте xml, смёрженный из 5-10 xml может быть от 100-150 MiB и выше, как повезёт. В этом случае открытие файла в np++ становится мучением, как и работа с ним.
                                  0
                                  Раньше использовал EditPlus2 (не помню, почему отказался частично), до 50Мб он переваривал не морщась, больше не пробовал.
                                    0
                                    При открытии большой пачки файлов, пусть даже мелких, на сотню байт-пару килобайт, зависает на иногда до 5-10 секунд, на так и не посчитал каком по счёту файле, что-то после 120, но не всегда на одинаковом количестве. (вот сейчас проверил — завис, правда только на пару секунд, на 127-ом)

                                    Я тоже отказался от него в больше части предыдущих операций и перешёл на AkelPad. Он оказался лучше Notepad++.
                                      0
                                      Если не секрет, зачем нужно открывать 100+ файлов одновременно? А если какое-то однотипное массовое редактирование, то уж проще скриптами. Ну и пару сек — это не катастрофа. Многие редакторы один файл открывают дольше.
                                        0
                                        Пара секунд только сейчас, при открытии же «обычной пачки» из ~200-300 файлов — зависает на заметное время.

                                        Для перевода делаю копию файлов. А им нужно иногда конвертирование между форматами (из Unix в Win) и изменение кодировки (последнее можно автоматизировать).
                                        После покупки автором оригинала — огрызкобука, часть файлов он стал сохранять в формате Unix. Изредка он заменяет много файлов, бывают сбои синхронизации и резервного копирования. На самом деле такое редко нужно, но всё же бывало, такое приходилось делать массово.
                                        Да, можно написать конвертер и я писал один (но только для смены кодировки), но он тоже не универсален, тем более учитывая, что иногда файлы для работы нельзя выделить из всей пачки :(.
                                          0
                                          Осталось понять чем вам perl-скрипт на 20 строк не угодил и зачем для конвертации вообще привлекать редактор.
                                            0
                                            «Осталось понять, чем...» вы читали предыдущий комментарий :(. В котором я достаточно полно описал, зачем мне нужен редактор, да, помимо двух «конвертаций»!
                                            А ещё, помимо самого скрипта, мне внезапно(!) понадобится интерпретатор — сам perl. Офигенный «скрипт», угу.
                                            А ещё, он делает только одно, довольно редко нужное действие, но не делает второе, самое важное конвертирование — смену кодировки.
                                              0
                                              А ещё, он делает только одно, довольно редко нужное действие, но не делает второе, самое важное конвертирование — смену кодировки.
                                              Смену кодировки делает iconv.

                                              А ещё, помимо самого скрипта, мне внезапно(!) понадобится интерпретатор — сам perl.
                                              На любой современной Unix-системе он есть. А откуда у вас возьмутся файлы в Unix-кодировке если у вас нету Unix'а — для меня загадка.

                                              В любом случае если такое происходит не один раз в жизни, то проще поставить CygWin, чем забивать гвозди микроскопом, если один раз — можно и потерпеть пока редактор эти файлы откроет…
                                                0
                                                В любом случае если такое происходит не один раз в жизни, то проще поставить CygWin, чем забивать гвозди микроскопом

                                                Забивание гвоздей микроскопом — это как раз куча мусора в системе в виде cygwin'ов, перлов и прочей ненужной гадости для решения одной задачи.

                                                  0
                                                  Ваши комментарии оскорбляют мой разум! Даже не знаю, чего в них больше — издёвки, насмешки или просто оскорбления.

                                                  Вы второй раз не потрудились прочитать, видимо лозунг — «комментарий не читай, ответ строчи», вам весьма близок?

                                                  Ezhyg 24.09.18 в 00:41
                                                  После покупки автором оригинала — огрызкобука, часть файлов он стал сохранять в формате Unix

                                                  khim 24.09.18 в 04:30
                                                  А откуда у вас возьмутся файлы в Unix-кодировке если у вас нету Unix'а — для меня загадка.

                                                  Для меня загадка — диагноз, который можно поставить по этой цепочке комментариев.
                                                  Вдобавок даже в предыдущем комментарии вы, похоже, так же не потрудились прочитать комментарий на который решились ответить, с как бы «желанием» помочь.
                                                  Смену кодировки делает iconv.

                                                  Я рад за него, чесслово! Мало того, изредка, даже использую его помощь.

                                                  На любой современной Unix-системе он есть.

                                                  Не на любой. Но это и не важно, при чём тут юниксы ваще? EditPlus2 — Windows программа, как я могу работать в ней, при этом конвертировать что-то скриптом питона, а затем айконвом? (только не вздумайте мне рассказывать про вторую машину или виртуалки)

                                                  В любом случае если такое происходит не один раз в жизни, то проще поставить CygWin, чем забивать гвозди микроскопом, если один раз — можно и потерпеть пока редактор эти файлы откроет…

                                                  Да уж… тащить огромный пакетище для мелких разовых вещей — очень по красноглазиковски!
                                                  Здесь я согласен с Druu

                                                  Если уж вы решили комментировать, то будьте добры, потратьте своё, безусловно бесценное, время и прочитайте уже комментируемое!
                                                    0
                                                    Не оскорбляйтесь так сильно. Я, например, долго пытался понять, автор какого именно оригинала купил огрызок, и почему он, автор, решил сохранять в Юникс-формате.

                                                    Опять же, программисты наверное предполагают, что у вас есть возможность хоть на чем-то написать маленький скрипт. Наверняка, не пытаясь этим вас обидеть.

                                                    Ну а айконв, наверное, посоветовали, поскольку вы писали свой велосипед.

                                                    Никоим образом не пытаюсь оскорбить ваш разум. Может, я не совсем понял, что он писал и как думал, поэтому заранее прошу у него прощения.

                                                    Надеюсь, мой незаангажированый комментарий убедит вас, что вас не хотели обидеть.

                                                    Что до сотен файлов открытых в редакторе — то, очень интересное наблюдение. Прям как в том анекдоте, на любую бензопилу, найдется рельса которая её сломает. Интересно, сколько сотен или тысяч файлов повесят редактор окончательно.
                                                    Да, так и не понял каким именно вы пользуетесь.
                                                      0
                                                      Я никогда не оскорбляюсь, не вижу смысла. Чего и вам желаю :D

                                                      долго пытался понять, автор какого именно оригинала купил огрызок, и почему он, автор, решил сохранять в Юникс-формате.

                                                      Автор оригинала (файлов), переводимого мной (слово перевод вам надеюсь понятно?)

                                                      Формат Юникс, потому что огрызкобук же, потому что там этот формат вообще-то по умолчанию в его редакторе. А не самого мак-а, потому что его редактор — *никсовый, а не яблочный.

                                                      Опять же, программисты наверное предполагают, что у вас есть возможность хоть на чем-то написать маленький скрипт. Наверняка, не пытаясь этим вас обидеть.

                                                      поскольку вы писали свой велосипед.

                                                      Так я и написал. Хотя это не скрипт и уж точно не велосипед! Нормальная команда запуска редактора без гуя (консольно), с параметрами конвертирования из одной кодировки в другую. И я сразу же объяснил, что конвертировать надо «два раза», но нет… начинается снова предложение вначале одного, на перле, потом второго на пхп, да и вообще не под ту ось. Это же клиника!

                                                      Что до сотен файлов открытых в редакторе — то, очень интересное наблюдение.

                                                      Я же говорю, это бывает нужно редко, ну какие буквы-то незнакомы? :(
                                                      Тем более, не важно — отдельно я сконвертирую или вместе, мне же всё равно эти файлы открывать и редактировать.
                                                      Всего файлов там около 3800, но ни разу ещё не было чтобы «испортилось» больше пары сотен.

                                                      И я описал почему я так же отказался, как и автор комментария, прокомментированного мной.
                                                      Раньше использовал EditPlus2 (не помню, почему отказался частично)


                                                      0xd34df00d в репах есть:
                                                      безазотистые вещества (6,5 %), азотистые вещества (1,1 %), жиры (0,2 %), минеральные соли (в нём очень большое содержание кальция), витамины (А — 0,04 мг, С — 8—20 мг, B1 — 0,08—0,11 мг), значительное количество сахаров и витамина PP. Богата янтарной кислотой.

                                                      Никаких dos2unix там нет! Это ген такой или вещество?
                                                0
                                                Осталось понять, зачем тягать какие-то непонятные скрипты, если в репах есть dos2unix.
                                  0
                                  Notepad++ не очень, т. к. не предназначен даже для самого базового редактирования кода (не поддерживает Tab indent space align). Зато зачем-то поддерживает подсветку кода. Бред.
                                    +1
                                    Подсветка кода сильно нужнее. Хотя выравнивание не помешало бы, есть такое.
                                      0
                                      Но и подсветку значительно сложнее сделать. На несколько порядков.
                                        0
                                        Это чем сложнее?)
                                        Какая разница какой фон под символом?
                                        Красный, белый или зилёный?
                                        Почему белый фон под символом рендерится за 10мс, а красный фон за 100мс?))) Цыфры условные.
                                        Вы вообще понимаете, что разницы в принципе нет никакой? И не должно быть.
                                        Разница получается в таких вот поделиях исключительно потому, что поделие сделано из говна и палок. Подсветку прикручивают не на том уровне абстракций. Всего навсего…
                                          +2
                                          Для подсветки нужен хоть какой-то синтаксический анализатор конкретного языка. На регулярках или строящий AST, обрабатывающий весь файл целиком или потоковый, в основном потоке или в фоновом процессе, но анализатор. Для каждого языка.
                                            –1
                                            Ага ага…
                                            Вы еще скажите, что отрисовка процессором символа с фоном медленней, чем определение того какой под символом фон нужен.
                                              0
                                              Причём тут это?
                                                –2
                                                Как это причем?
                                                У вас решение какое-то дичайшее.
                                                Вы говорите что парсить строчьку дороже, чем символ с красным фоном рисовать.
                                                ВЫ ОБЪЯСНИТЕСЬ ХОТЯ БЫ КАК-ТО??? Как такое может быть вообще?
                                                Или вы что не понимаете, что вы люто бредите??
                                                  +3
                                                  Какую строчку? А если 900 строчками выше объявлен символ начала комментария?
                                                    +1
                                                    Вообще то тут сильно зависит от того, что парсить и как рисовать. И на каком железе. Парсинг строки кода на C++ может быть сильно медленнее, чем отрисовка символа 16х16 пикселей с заданным фоном.
                                                    А вообще мне кажется, Вы с VolCh о разных вещах говорите. Вы — о времени выполнения, а он — о времени разработки.
                                                      0
                                                      Особенно учитывая, что парсинг C++ неразрешим в смысле Тьюринга и требует полноценного интерпретатора C++.
                                                      0
                                                      Конечно парсить строчку, иной раз в несколько мегабайт длиной, дороже, чем рисовать сиволы с разным цветом фона. Как минимум в случае когда символы мы по любому рисуем и нам нужно лишь определять каким цветом и с каким фоном их рисовать.
                                                        0
                                                        В реальность вернитесь уже.
                                                        У вас строка бывает длиной в несколько мегабайт? И зачем подсвечивать эту строчку длиной в мегабайт?
                                                        Вы про какой парсинг сейчас говорите?
                                                        Давайте разбираться. Парсинг всего документа целиком — это одно. И да, совершенно прав человек, когда пишет, что если начало комментария 900 строчками выше, то надо парсить весь документ. Так символ комментария может быть не только на 900 строк выше, а выше еще и на 1800-ой строке. Комментарий кто-то попытался сделать вложенным например. И не надо говорить что где-то это запрещено, а где-то разрешено, и где-то документ будет валидным, а где-то нет. Суть не в этом. Парсить ДОКУМЕНТ в любом случае нужно. Но я не про парсинг документа) Я про парсинг строки. Т.е. где в строке подсветить символы. Я про графику. И только. Т.е. есть строка, уже распарсенная. Так вот вам в этой строке нужно подсветить исходя из распарсенного — символы 10,11,12, 34,35,36 и т.д. Вот это и тормозит. А тормозить не должно никак. Имея именно распарсенный документ любой, т.е. абсолютно любой — тормозит именно подсветка символов. Это же увидеть абсолютно легко. Берете документ на 10кб и на 10мб — подсветка тормозит в обоих случаях. И тормозит именно определение того, где какой символ подкрасить, т.е. фон поменять. А фон меняют через лютые костыли зачем-то. Вот это и тормозит больше всего.
                                                        Выходит так, что тормозит не парсинг документа, а графика. Это как с курсором выжирающим ядро. Типа того.
                                                          0
                                                          Документ состоит из строк. Распарсить документ = распарсить все строки. И это вам нужно вернуться в реальность, где строки никто не парсит снова, чтобы подсветить её части. Определение цветов символов в строке — это не парсинг.
                                                            0
                                                            Да что вы говорите) Т.е. если вы получили некую структуру данных о документе, то в ней что-то сказано о том где и как красить фон символов? Наложение раскраски тоже никто не отменял. Закомментированное что-то может быть тоже внутри раскрашено, но бледно. Перенос строки разве кто-то отменял? И как вы в такой строке красить собираетесь? А если идут 20 табов и строка уходит за экран? Тоже подкрашивать то что ушло за экран? Вам графическую часть парсить придется и еще как. И да, тут нужно будет тоже парсить. И это парсинг тоже.
                                                              0
                                                              Наложение — это наложение, проецирование если угодно, может разметка, но никак не парсинг. И до графической части там ещё далеко.
                                                          0
                                                          А до какого уровня парсить, насколько подробную подсветку мы хотим?
                                                          Рисовать буквы одним цветом, цифры другим, прочие символы третьим — элементарно и почти ничего не стоит. Подсветка ключевых слов, строк, комментариев — уже зависит от синтаксиса языка. Выделить имена классов, элементы перечислений, парные скобки — нужен полноценный парсер. Неиспользуемые параметры? Неинициализированные переменные? Теперь рисование разноцветных символов требует транслятора с анализом dataflow…
                                                  0
                                                  Я имею ввиду реализовать подсветку синтаксиса в редакторе программного кода на порядки сложнее, чем реализовать в редакторе tab indent space align.

                                                  Во втором случае понадобится всего несколько строчек кода, а в первом месяцы или даже годы работы (если делать в одиночку, придумать кучу всяких тем, поддержать 100 языков программирования, для каждого из которых нужен синтаксический анализатор, сделать всё оптимайзно, красиво в архитектурном плане и т. д.).

                                                  Так вот, Notepad++ решил пойти по странному пути. Потратить годы работы на подсветку синтаксиса — это ок, а потратить 5 минут времени на Tab indent space align — не ок, хотя эти две фичи одинаково важны.
                                                    +2
                                                    Ну, на счет одинаково важны — это все таки субъективно. Я вот вообще почти не слыхивал про tab indent space align, а подсветка синтаксиса очень помогает.
                                        +1

                                        Если отключить из редактора intellisence, подсветку синтаксиса, то вероятнее он откроется быстрее. Тот же sublime, если автоматом не поставит подсветку синтаксиса, то может открывать файлы в разы больше чем с подсветкой. Хотя Vim например и с подсветкой открывает достаточно шустро.

                                          +7
                                          Блокнот++ открывает быстрее секунды с подсветкой. На самом деле там 2 проблемы
                                          1. подсветка. У многих она тормозит. У некоторых — безбожно.
                                          2. Весь файл в одну строку. Такая подстава многие редакторы ставит на колени. Как пример: PSPad с подсветкой справляется, а вот с однострочниками нет. Более того, там даже прокрутка будет безбожно тормозить (если вкл автоматический перенос)
                                            0
                                            Помнится перестал использовать PSPad после того как надоели постоянные падение при попытке открыть хотя бы метровый файл
                                              0
                                              Та же самая ситуация, сам по себе PSPad был отличным продуктом, но если бы не эти мелочи. Но зато я открыл для себя существование Notepad++ и Sublime Text
                                                0
                                                Если бы ещё в Notepad++ можно было бы редактировать программный код. Туда зачем-то впихнули подсветку синтаксиса, а какой в этом толк, если всё-равно не поддерживает tab indent space alignment.
                                                  +1
                                                  tab indent space alignment

                                                  И это всё?
                                                    0
                                                    Подсветка синтаксиса в Notepad++ полезна тем чтобы глаза не вытекали и чтобы можно было, например, скрипт для cmd отредактировать. А для редактирования кода и разработки есть IDE, её и необходимо использовать.
                                                      0
                                                      Имеющаяся IDE неповоротлива и бедна на подсветку синтаксиса, поэтому используется Notepad++
                                                      0
                                                      А что мешает самим написать плагин?
                                                        +1
                                                        1. Написал бы, но я работаю с другими языками программирования.
                                                        2. Это странно, для такой базовой функциональности писать плагин. Давайте ещё напишем плагин нажатия клавиши Enter, чтобы перенести курсор на следующую строку, предваритально создав её, потом напишем плагин для стрелок — а чё, хочешь перемещаться по коду, ставь плагин! и т. д.
                                                        3. У notepad++ есть какие-то баги с плагинами — не сохраняются настройки.
                                                        4. Но конечно же всегда можно сделать Pull Request! Но даже если бы я писал на этом языке, то не знаю, стал ли бы я делать. Потому что когда языки совпадали, я пулл реквестил аж в 5 проектов. В двух из них авторы до сих пор рассматривают их уже 2 года (хотя перед pull request'ом я с ними общался, они были не против изменений). Казалось бы, всё готово, им нужно только одну кнопку нажать и смержить изменения, но нет. В одном проекте исправил ошибку, но pull request тупо отклонили, сказав, что не хотим мы ваших исправлений. И только в двух проектах pull request'ы без проблем приняли.

                                                          Выяснять отношения и годами просить принять pull request поднадоедает. Хочется просто взять, реализовать фичу, и всё, а не заниматься не пойми чем. Хочется заниматься именно программированием.
                                                          0
                                                          хм
                                                          • вы перемещаетесь по коду стрелочками
                                                          • «Выучить новый язык программирования» на уровне написания плагина непосильная задача

                                                          да практически герой статьи в топике.
                                                            0
                                                            Необязательно непосильная, но значительно усложняет процесс. Вместо того, чтобы взять и написать, нужно вначале изучить язык, потом разобраться как писать эти плагины, подключать и т. д.

                                                            И самое главное — ради чего? Ради того, чтобы следующий человек пришёл и сказал «А где tab indent space alignment?»? Ну да, наверное, найдёт плагин в гугле. По факту плагин уже есть давно. Но работает плохо. +В Notepad++ не сохраняются настройки плагинов.
                                                              0
                                                              Не замечал такой проблемы. Может, это из-за того что программа с плагинами поставлена в папку Program Files запись в которую под правами пользователя по умолчанию системой пресекается.
                                                                0
                                                                Интересно, а куда ещё ставить программы, кроме как в Program Files? И по идее плагины должны хранить настройки в аппдате, там же, где хранят свои настройки другие нормальные приложения
                                                                  0
                                                                  Должны, но приложение можно поставить и по старинке, оно будет всё хранить в своей папке получая каждый раз облом. А в новой винде есть ещё и прозрачный механизм переноса этих файлов в профиль для старых приложений, они не заметят подвоха. Может, механизм как-то неправильно работает — насройки исправно сохраняются, но плагины пытаются читать их по старому месту?
                                                                    0
                                                                    Может, механизм как-то неправильно работает — насройки исправно сохраняются, но плагины пытаются читать их по старому месту?

                                                                    Вряд ли. Это нужно сохранять настройки от пользователя, а запускать от админа, только тогда отключится виртуализация файловой системы.
                                                    0
                                                    Странно. Сам активно им пользовался и падений особо не припомню. Отказался как раз из-за невозможности работы с большими однострочными файлами (дичайше тормозил). Но если файл порубить предварительно на строки — вполне норм. Для нарезки использовал EditPlus2, он без проблем пережевывал 50+метров (больше просто не пробовал)
                                                      0
                                                      Я в читерскую бытность частенько открывал непотребные файлы текстовыми редакторами. Переживали такое немногие. Это было году в 2004 в расцвет WinXP и тогда много чего под винды отваливалось по разным причинам.
                                                  +1

                                                  Ну сделай ты подсветку синтаксиса отдельными потоком, чтобы не мешать пользователю пользоваться твоей программой.
                                                  Сперва разработчики для iOS догадались (ОК, их заставили) переносить тяжёлые и долгие операции в фоновые потоки.
                                                  За ними подтянулись разработчики для Android.
                                                  А на десктопах всё так же по старинке всё одним потоком, последовательно — если у пользователя комп тормозит, то пусть купит себе новый, ага.

                                                    +1
                                                    Интересно, за что Вас заминусовали…
                                                      0
                                                      Ну у джетбрейнс парсинг отдельным потоком или процессом
                                                        +1

                                                        За это мы их и любим.
                                                        Но очень многие разработчики ожидают, что их творения будут работать в идеальных условиях, на быстрых процессорах, с достаточным количеством памяти, с быстрой и всегда доступной сетью и т.п.

                                                          +1
                                                          … с правами админа (десктоп), с доступом ко всем возможным действиям, нужным и ненужным, но пусть будут (мобайл)…

                                                          Первое еще можно понять — сисадмин по своей лени выдал разработчику полные права для изменения либ и прочего, вот последний так же ленится релогаться туда-обратно и пишет под админом. Ваше право, возьмите да укажите в требованиях к установке полные права. Нееет, мы умолчим о том, что разработка у нас через одно место, а юзер пусть грешит на себя — то ли комп глючит, то ли ОС криво встала… Из последнего — надстройка Overwolf для TeamSpeak3: под юзером запускалась, все рисовала, но не коннектилась к ей же запущенному TS3.
                                                          Порой доходит до абсурда — пользовался плагином EveryHTTPS, и на одном из сайтов сертификат был выдан на айпишник локалхоста, то есть у админа всё работало…
                                                          0

                                                          Чтобы делать что-то в отдельном потоке — нужны на порядок более квалифицированные разработчики. Без этого ловим глюки и тормоза (потоки ждут друг друга — не раз наблюдал, как в несколько потоков оказывается медленннее, чем в 1).

                                                            0
                                                            Ну, я думаю, такие вещи, как посветка синтаксиса, в любом случае квалифицированные разработчики делают, не?
                                                              +1
                                                              нужны на порядок более квалифицированные разработчики.

                                                              Что значит «на порядок более квалифицированные»? Человек, если вообще способен быть программистом, способен и освоить многопоточность. Многопоточность может потребовать больше внимательности и времени на проектирование, но для её использования не нужно какое-то профессиональное просветление. Это такой же обязательный навык для любого программиста (кроме тех, кто пожизненно связался с какой-то принципиально однопоточной платформой), как и умение делать циклы. Просто проходится на чуть более поздних лекциях.
                                                                0
                                                                Я бы согласился, если бы не истории, что физзбазз для людей просто рокет саенс.
                                                                  0
                                                                  Не забывайте, что в коде неминуемо будут ошибки, которые потом придётся искать. Как по вашему, достаточно для этого «пройти многопоточность на более поздних лекциях»?

                                                                  Конечно, сейчас есть методы, позволяющие кардинально уменьшить сложность многопоточного кода (например, делать все данные либо локальными, либо immutable — вроде современные языки даже научились жёстко устанавливать это ограничение), но всё равно сложности хватает.
                                                              0
                                                              Проблема в том что эту подсветку и структуру данных которую читает процесс редеринга надо синхронизировать. И тут мы получаем два варианта: или отрисовка пишет непосредственно в структуру которой оперирует рендер и огромные процессорные ресурсы улетают на обработку блокировок или у синтаксиса своя копия отрисока с ней сверяется по необходимости и мы имеем примерно удвоенное потребление памяти.
                                                                +2
                                                                у синтаксиса своя копия отрисока с ней сверяется по необходимости и мы имеем примерно удвоенное потребление памяти.

                                                                С одной стороны, да. С другой стороны, я помню, как четверть века назад притормаживала подсветка синтаксиса в Turbo Pascal 7 на компьютере «Поиск 1.04». Было примерно как сейчас у меня в браузере при комментировании этой ветки. Лагало, неприятно было, но работать было можно.
                                                                Checkit показывал, что быстродействие того «Поиска» было на уровне 0,5 от IBM PC XT (там был 16-битный проц на 5МГц, 608К ОЗУ, и программная эмуляция видеоадаптера IBM CGA). И там подтормаживала подсветка синтаксиса. Блин, но я никак не могу понять, почему она в некоторых IDE подтормаживает сейчас, на восьми 64-битных суперскаляных ядрах по 4ГГц каждое.
                                                              0
                                                              да. vim почти всегда шустро.
                                                              любопытно за счет чего
                                                              +9
                                                              XML хороший пример, но в другом смысле. Среди читающих это есть некоторая доля программистов, некоторым из них приходилось парсить XML. Сколько из них пользовались XML DOM парсером, который по определению жрет память, а сколько гораздо более экономным XML SAX парсером? Вот то-то же, DOM настолько удобен для программиста, что в 99% процентов случаев ему прощали его цену. А из десятков таких нюансов и складывается общий оверхед.
                                                                +4
                                                                На самом деле sax\dom — это фигня (хотя да, скорость там очень отличается). Недавно столкнулся с кодом, который на больших объёмах почему-то (только у клиента) дико тормозил. Практически экспоненциально! Т.е. для файлов в 100 кб вывод занимает секунд 10, а метр — уже к часу дело идёт. Начал разбираться. Оказалось файл формируется по шаблону, а шаблон тупо нарезается на блоки, из которых собирается файл. String.replace-ом. В итоге у разраба на машине с 16Гб оперативки всё работает, а вот у клиента с 2..4Гб моментально выжирается вся оперативка и дальше становится всё очень печально…
                                                                  +3

                                                                  Напомнило, как я в своё время всадил фееричную багу.
                                                                  После нескольких часов работы программа начинала тормозить. Причина: в ней было отладочное окошко с текстбоксом лога, в который я при обработке очередного блока данных добавлял точку (что-то тип dbgForm.textboxLog.Text.Append(".") — дело было на дельфях). Что с каждой точкой оказывалось всё медленней...

                                                                    0
                                                                    В драйверах Qualcomm как-то нашли кусочек кода, где для того, чтобы найти максимум в массиве, его сортировали по неубыванию. Пузырьком.
                                                                    Это драйвер, т.е. критичный к производительности код. Для мобильных устройств. От Qualcomm.
                                                                      0
                                                                      Если массив маленький, то не критично. Но зачем так криво делать? Можно просто в цикле прогнать один раз.
                                                                        0

                                                                        Да возможно все гораздо проще — исходно надо было сортировать небольшой массив или его часть, сделали пузырек, потом требования изменились и оказалось, что нужен только один элемент, а пузырек остался, т.к. не стали все переделывать.


                                                                        Почему-то многие забывают, что код не всегда пишется оп и сразу, зачастую он не раз рефакторится, прежде чем дойти до продакшена.

                                                                    +9
                                                                    Абсолютно точно.
                                                                    То ли в 2014, то ли в 2015 у нас налоговая приняла законы, по которым XML-ины электронной отчётности по размеру стали допустимы до 10гб (вроде бы с изначального «копеечного» лимита 10-100мб), так все решения на DOM'ах очень красиво посыпались, когда пошли клиенты с громадными «контролируемыми сделками» и «книгами для ндс». Потому что DOM одной только памяти жрёт х10 от размера файла, и если раньше (100мб-1гб) на это закрывались глаза, то на 100гб глаза уже не закроешь, не говоря уже о платформе х86.
                                                                    Делал в те времена в системе электронной отчётности проект по уходу с DOM (легаси было крепко на него завязано, XPath и прочие плюшки активно использовались) на SAX в один пробег, с «эмуляцией» плюшек или обоснованным отказом от них — веселья было много. Теперь в резюме указываю тег XML, а на собеседованиях периодически посмеиваются, мол, что там знать-то, древовидная структура, теги/атрибуты и всё. Так-то оно да, но, как и в физическом мире, когда масса объекта пересекает определённые границы, проявляется много интересных эффектов, о которых даже не думаешь, щупая маленькие объекты.
                                                                      0
                                                                      Мы с этой проблемой лет на 10 раньше столкнулись. Объёмы тогда были не такие, но 50..100 метров на тех машинах тоже было не подарком.
                                                                      +1
                                                                      Однопроходный алгоритм в ленивом DOM-парсере вполне может быть O(1) по памяти.

                                                                      Да, я такое писал с одним из хаскелевских DOM-парсеров. Было очень удобно, приятно, естественно и эффективно.
                                                                        0
                                                                        Но это уже не DOM.
                                                                          +3

                                                                          Почему?


                                                                          Надо разделять стратегию вычисления и API, тем более, что сайд-эффекты остаются все те же. Ну, да, если там невалидный документ, то я получу ошибку чуть позже, возможно, потратив ресурсы процессора на обработку валидного куска DOM-дерева. Ну так с SAX бы то же было бы.

                                                                            0
                                                                            Это сильно зависит от структуры документа. Бывают форматы, где есть ссылки из начала в конец, т.е. для обработки самого начала уже надо иметь доступ ко всему файлу. И загружать его всё равно придётся полностью. Так что никакое О(1) не отменит того, что грузиться оно будет медленнее и памяти занимать сильно больше. Причём второе — бессмысленно, т.к. программы обычно всё-таки не работают с самим деревом, а просто загружают его в свою структуру просто дублируя данные.
                                                                              0
                                                                              Ну, в этом случае можно просто сохранить ссылку на кусок в конце.

                                                                              А вот если вам нужно посчитать, скажем, 0.95-персентиль по некоторым нодам в документе, это уже может быть болезненно, да.
                                                                                0
                                                                                В смысле? Чтобы сохранить ссылку нужно сначала распарсить весь файл и найти, куда ссылаться, т.е. нужна доп логика над парсером. Проще sax-ом обработать в один проход. А ещё ссылки бывают не только вперёд, но и назад. DOM для того и нужен, чтобы работать с рандомным доступом, без этого смысла в нём нет.
                                                                                  0
                                                                                  Ну это уже от конкретной задачи зависит, так сферически в вакууме трудно обсуждать конструктивно, но смысл в том, что встретили ссылку вперёд — сохранили в список соответствующий предикат. Тогда вы будете O(n) по числу предикатов/ссылок, а не по всему объёму документа.

                                                                                  А иногда оказывается выгоднее тупо распарсить документ два-три раза, зато каждый раз в один проход.
                                                                                    0
                                                                                    Вот только вы, похоже, не учли один нюанс. В этом случае парсер(!) должен знать структуру конкретного файла, чтобы понимать, что является ссылкой, а что якорем. Что слегка убивает идею универсального псевдо-dom. Imho на этом этапе проще перейти к нормальному sax, это будет проще, чем морочиться со всей лишней логикой чтобы вкорячить сюда то, что тут не требуется. (троллейбус.jpg)
                                                                                      0
                                                                                      Зачем это парсеру знать? Парсер просто выдаёт ленивое дерево нод, знать это нужно вам, когда вы по этому дереву проходите.
                                                                                        0
                                                                                        Парсер просто выдаёт ленивое дерево нод

                                                                                        А как парсер сможет выдать дерево нод (не важно лениво или нет), не зная структуры документа?


                                                                                        Вообще по такой логике можно любую задачу решить за О(1) — объявить что ф-я, которая делает то, что нужно, ленивая, и не запускается, т.к. оказывается не нужна.
                                                                                        В итоге можно мгновенно решать np-задачи.

                                                                                          0
                                                                                          А как парсер сможет выдать дерево нод (не важно лениво или нет), не зная структуры документа?

                                                                                          А зачем парсеру знать структуру? Парсер — это синтаксис, структура — это семантика конкретных элементов. XML-парсеру пофиг, OOXML там, налоговые выверты или XHTML.

                                                                                          И если это ссылки, скажем, в смысле примечаний формата fb2 какого-нибудь, то не вижу проблем.
                                                                                            0
                                                                                            Ок. Пусть fb2.
                                                                                            Есть док, у которого в самом начале ссылка на картинку с обложкой, которая лежит в конце. Когда клиент захочет сразу же отобразить обложку (ну он же работает с dom и уверен, что она уже загружена) вы предлагаете:
                                                                                            1. загрузить весь документ до обложки и работать как с обычным dom?
                                                                                            2. дропнуть всё до обложки а потом начать парсить сначала, когда клиент продолжит читать документ с начала первой главы?
                                                                                            3. ???
                                                                                              0
                                                                                              Когда клиент захочет сразу же отобразить обложку (ну он же работает с dom и уверен, что она уже загружена)
                                                                                              Даже если она уже загружена — поиск в нём долог и дорог. И да, сложить две строки — это тоже дорого и сложно. Как и выделить подстроку. И как изменить регистр. И как многое другое. Лучше всего про эту банальность (как и почти любую другую банальности) описал Джоел

                                                                                              Если вы будете помнить, о том, что поиск в DOM — это дорого и долго, то у вас всё будет работать быстро и с DOM'ом и, чуть медленнее (но со значительной экономией памяти) — с «ленивым» DOM'ом. Если же вы будете считать, что складывать строки легко и быстро — то вам, извините, никакие абстракции не помогут. Скорее помешают.

                                                                                              У меня есть ощущение, что вина всему — то, что начинающие программисты больше не начинают с Бейсика на C64. Когда вы писали на языке, который был в 100-500 раз медленнее (не в 100500, а в 100-500 — это довольно точная оценка), чем тот же алгоритм в машинных кодах и при этом процессор у вас был частотой 1 (один) мегагерц… то увидеть, что операции со строками — таки медленные можно было почти что невооружённым глазом. А сейчас — сеньор-программисты об этом не подозревают… а абстракции… абстракции могут быть любыми — важно только не забывать, что все они — дырявые
                                                                                                0
                                                                                                Собственно на вопрос вы так и не ответили. Те, кто понимает, что dom — это медленно и дорого — его по возможности не используют, так что речь не о них. И при повторном чтении там будет совсем не чуть медленнее (тем более что построение dom уже само по себе весьма затратно). Да и речь вообще была о том, что просто так заменить dom на ленивый нельзя. А не просто так — почему сразу не использовать sax?
                                                                                                  0
                                                                                                  А не просто так — почему сразу не использовать sax?

                                                                                                  Для униформности.

                                                                                                  Впрочем, я тут ещё подумал и понял, что в ленивом сеттинге разницы между DOM и SAX нет вообще. Что там функция, паттерн-матчащаяся на ноды, что там функция, паттерн-матчащаяся на выплевки SAX-парсера.

                                                                                                  И если вспомнить, что в ленивых языках всякие списки, ленивые деревья и прочее — это скорее управляющие структуры, а не структуры данных, то это начинает иметь всё больше и больше смысла.
                                                                                                    0
                                                                                                    Для ленивых — может быть. Для остальных — наоборот, меньше смысла, т.к. логика обработки меняется.
                                                                                                0
                                                                                                Если у меня недостаточно памяти, то я бы делал (2), в первый проход дропая всё, кроме обложки. SAX'ом вы тоже два прохода будете делать, впрочем.
                                                                                                  0
                                                                                                  Вы меня упорно отказываетесь понимать. Какие 2 прохода? Вы работаете с dom! В sax всё прекрасно делается за 1 проход. Речь не о нехватке памяти, а о дублировании в памяти всего документа в dom.

                                                                                                  А если вы работаете проходами, то на кой чёрт вам dom, если всё равно алгоритм работы полностью меняется. IMHO ленивый dom имеет смысл только при простой последовательной обработке, когда очень лень эту обработку писать. Да и то по факту сильно проще там не станет.
                                                                                                    0
                                                                                                    Как вы с SAX решите вашу задачу с fb2 выше в один проход?

                                                                                                    DOM мне затем, что, с учётом ремарки выше, это вопрос того, кто оборачивает поток XML-сущностей (тег/атрибут/етц) в управляющую структуру. Мне удобнее, когда это уже сделали за меня, чем строить дерево ручками.
                                                                                                      0
                                                                                                      А в чём проблема? Мы же знаем, что картинка будет позже в добавим, когда дойдёт до неё дело. А вот работающие с dom такими вопросами обычно не заморачиваются, т.к. по идее всё дерево доступно полностью сразу.

                                                                                                      Это всё хорошо, когда вы пишите редактор xml или сериализацию один-в-один. Но когда данные в памяти не соответствуют структуре файла (а обычно так и бывает) — их всё равно придётся преобразовывать. И когда это делать разницы нет. Хоть при обработке потока xml, хоть выгребая из дерева. Но первое быстрее и требует меньше памяти.
                                                                                                        0
                                                                                                        А вот работающие с dom такими вопросами обычно не заморачиваются, т.к. по идее всё дерево доступно полностью сразу.
                                                                                                        Никогда оно не бывает «доступно всё сразу». если всем известные числа вспомнить, то легко понять, что переход к следующему элементу — это что-то типа 0.5 нс (обращение к кешу L1), у куда-то «вдаль» — что-то типа 100 нс. Разница — два порядка. И да, это в полностью распарсенном и загруженном дереве.
                                                                                                          0
                                                                                                          Всё-таки речь не о том, что они не бесплатны, а о том, что об этом никто не задумывается. Особенно с учётом того, что на загрузку там тратится на много порядков больше времени, чем на доступ. Собственно на фоне загрузки доступ уже можно считать условно бесплатным. Ну не считая случаев, когда загрузка засрёт всю память и мы будем работать со свопом. Это к обработке уже не относится.
                                                                                                            0
                                                                                                            Особенно с учётом того, что на загрузку там тратится на много порядков больше времени, чем на доступ.
                                                                                                            Ой ли? А если прикинуть? Если доступ к памяти занимает 100 наносекунд, то на 10Гбит/с канале вы за это время загрузите 120 байт. То есть «много порядков» у вас будет только если ссылки из одного места в другое случаются пару раз в файле на мегабайт. Иначе — эти величины очень даже могут быть сравнимы.

                                                                                                            Собственно те самые числа «должен знать каждый» именно потому что часто вещи, которые «на много порядков больше времени» занимают вовсе не так много, как вам кажется — и соотвественно «очень простые и быстрые» вещи часто оказываются вовсе не такими «простыми и быстрыми»…

                                                                                                            Ну не считая случаев, когда загрузка засрёт всю память и мы будем работать со свопом.
                                                                                                            А почему, собственно? Если у вас система на SSD, то обращение к своп-файлу вполне может происходить на скоростях в несколько гигабайт в секунду… а вот если нужен произвольный доступ — то там числа совсем-совсем другие, конечно…

                                                                                                            Это к обработке уже не относится.
                                                                                                            А у чему это, я извиняюсь, относится? Если вам дадут XL-файл гиг на 10 — что вы ним будете делать?
                                                                                                              0
                                                                                                              100 наносекунд, то на 10Гбит/с канале вы за это время загрузите 120 байт.

                                                                                                              Да нифига вы за это время не загрузите. На один TCP-handshake куда больше времени уйдет.
                                                                                                                0
                                                                                                                Иначе — эти величины очень даже могут быть сравнимы.
                                                                                                                В сферических условиях в вакууме всё может быть. В общем случае на больших файлах разница будет и приличная
                                                                                                                А почему, собственно? Если у вас система на SSD, то обращение к своп-файлу вполне может происходить на скоростях в несколько гигабайт в секунду… а вот если нужен произвольный доступ — то там числа совсем-совсем другие, конечно…
                                                                                                                В основном потому, что изначально задача была в частности «не засрать всю память». А если это неизбежно — то не полагаться, что программа всегда будет работать на машине с топовым ссд неограниченного размера или как минимум с 128Гб оперативки.

                                                                                                                Вот мы плавно и вернулись к началу этого разговора, когда вместо нормального проектирования разработчик полагается на то, что железо всё вытянет.

                                                                                                                А у чему это, я извиняюсь, относится? Если вам дадут XL-файл гиг на 10 — что вы ним будете делать?
                                                                                                                Для начала я выясню, что, собственно с этим файлом требуется сделать. И если нет задачи написать клон excel — обычно требуется лишь загрузка из него значений, для чего пихать весь файл в память нет совершенно никакой необходимости.

                                                                                                                Если вдруг имелся всё-таки XML файл, то тем более. SAX-парсеру размеры файла совершенно не важны.
                                                                                                                  0
                                                                                                                  Если доступ к памяти занимает 100 наносекунд, то на 10Гбит/с канале вы за это время загрузите 120 байт.

                                                                                                                  Это сравнение апельсинов с бегемотами. Сравнивать задержку доступа с устоявшейся скоростью передачи несколько странно.

                                                                                                                  Если у вас система на SSD, то обращение к своп-файлу вполне может происходить на скоростях в несколько гигабайт в секунду… а вот если нужен произвольный доступ — то там числа совсем-совсем другие, конечно…

                                                                                                                  А если произвольный доступ не нужен, то можно снова лениво стримить всё дерево в DFS-порядке, и мы вернулись в начало.
                                                                                                                    0
                                                                                                                    Если доступ к памяти занимает 100 наносекунд, то на 10Гбит/с канале вы за это время загрузите 120 байт.
                                                                                                                    Это сравнение апельсинов с бегемотами. Сравнивать задержку доступа с устоявшейся скоростью передачи несколько странно.
                                                                                                                    Время есть время. Тот п#зд$ц, который мы тут наблюдаем в Хроме вот на этой самой странице с вероятностью 99% связан с тем, что кто-то исходил из логики: на загрузку там тратится на много порядков больше времени, чем на доступ… но применение этой логики достаточное число раз привело к тому, что… имеем то, что имеем то, что имеем: Chrome 54 — работает быстро, а «ускоренный» Chrome 69-70… вот так, как он работает…

                                                                                                                    А если произвольный доступ не нужен, то можно снова лениво стримить всё дерево в DFS-порядке, и мы вернулись в начало.
                                                                                                                    Не совсем. На SSD «ленивое» построение дерева приведёт, скорее всего, к ускорению. В оперативке — вряд ли. Но в случае, если человек считает, что произвольный доступ не стоит ничего и не учитывает того, что он, в общем-то, не так далёк от скорости работы сети… не поможет ничего!
                                                                                                              0
                                                                                                              Ну вот точно так же вы её лениво добавите, когда дело дойдёт до неё, и с DOM. Я перестал понимать ваше изначальное возражение о ссылках вперёд.
                                                                                                                0
                                                                                                                Я пытался объяснить, что вы используете сложный компонент с неизвестной внутренней логикой вместо быстрого и простого как полено, и при этом всё равно вынуждены использовать его как простой потому, как иначе не получится. Ну не смог и ладно…
                                                                                                      0
                                                                                                      А зачем парсеру знать структуру? Парсер — это синтаксис, структура — это семантика конкретных элементов.

                                                                                                      Парсер же возвращает АСТ (ну, условно, в общем АСТ может быть произвольным графом, а не деревом)? АСТ — это и есть структура документа, разве нет?

                                                                                                        0
                                                                                                        Это синтаксическая структура документа (как подсказывает расшифровка аббревиатуры).
                                                                                                          0
                                                                                                          С трудом представляюю как на основе исходного кода можно построить синтаксический граф не в виде дерева. Внутренние ссылки, перекрёстные, циклические, рекурсивные и т. п. уже не относятся, как по мне, к синтаксическому разбору, это уже дальше этап разбора дерева.
                                                                                                            –1
                                                                                                            Внутренние ссылки, перекрёстные, циклические, рекурсивные и т. п. уже не относятся, как по мне, к синтаксическому разбору, это уже дальше этап разбора дерева.

                                                                                                            В лиспе АСТ является произвольным графом.

                                                                                                              +1
                                                                                                              А можно пример недерева?
                                                                                                                0

                                                                                                                Штука в том, что ридер-макросы не являются токенами, и в них вы можете производить произвольного вида вычисления. Например — взять кусок АСТ и замкнуть его самого на себя:
                                                                                                                для
                                                                                                                #1=(yoba . #1#)
                                                                                                                получится бесконечный АСТ '(yoba yoba yoba yoba yoba ....)
                                                                                                                можно сделать такой цикличный АСТ, отдать на евал и он повиснет, например, ну или построить граф любого вида.

                                                                                          +1
                                                                                          Как был реализован IXMLDOMNode::parentNode?
                                                                                            0
                                                                                            Может быть и никак.
                                                                                            С чего вы взяли что оно ему надо было?
                                                                                            Он же не полную реализацию стандарта заваял. Полная реализация вообще никому не нужна, никогда.
                                                                                              +1
                                                                                              Но это уже не DOM.
                                                                                                0
                                                                                                Еще раз?) Давайте отвечу по-другому. Ему не нужная реализация полного дома. И вам не нужна) Она никому не нужна.
                                                                                                Человек отбросил лишнее, и алгоритмически оно у него полетело. При этом совместимость осталась.
                                                                                                В чем собственно проблема?

                                                                                                А проблема в том, что стремятся создать универсальную библиотеку, а это полная чушь. Потому что даже математически это невозможно. Если вы разгоняете что-то, то что-то просядет в другом месте.

                                                                                                В идеале же одна универсальная библиотека пусть будет, я не против, собрать проект не вдаваясь в подробности нужно быстро. Но для случаев кода дом не нужен полностью, должны быть другие реализации. И их должно быть много. Выбираете под себя вам нужную, т.е. ту которая максимально заточена под вашу конкретную задачу, а не ворох, а остальное там вообще не должно быть реализовано, ну потому что не нужно оно.

                                                                                                И кто так делает?) Никто. Потому что мозгов нет совершенно.
                                                                                                И поможет ли оно? Нет) Потому что нужно понимать из вороха узкозаточенных реализаций что они могут. А значит нужно все равно глубоко знать реализации. Так таких людей опять нет)

                                                                                                В итоге — вменяемых реализаций нет. Людей понимающих реализации тоже нет.
                                                                                                Что остается в сухом остатке, впрочем на самом деле в жидком? Правильно: только гавно.
                                                                                                  0
                                                                                                  Но для случаев кода дом не нужен полностью, должны быть другие реализации. И их должно быть много.

                                                                                                  Так а почему вы их еще не написали? Идите и пишите, вместо того чтобы в комментах говно обсуждать.

                                                                                                    0
                                                                                                    Можно же просто написать свою. Я в начале этого года пытался писать свой браузер. Разбивку на токены и построение DOM реализовывал сам. И оно работает вполне шустро (правда, на очень больших файлах пока не тестил)
                                                                                                0
                                                                                                Да чтоб я помнил, какой я библиотекой пользовался из тучи.

                                                                                                Мог быть просто завязанный узел, могло вообще не быть и делегировано на уровень выше (ну как в дереве тут).
                                                                                                  0
                                                                                                  Хм, библиотеку не помните, но уверены, что она обеспечивала O(1) по памяти? Звучит правдоподобно.
                                                                                                    0
                                                                                                    А вы помните все применённые вами библиотеки, языковые возможности и тому подобное в каждом нетривиальном случае 5-7 лет назад?

                                                                                                    Достаточно помнить своё удивление, в конце концов, что ты просто написал код с DOM-стилем беготни по дереву, а он просто за счёт ленивости скомпилировался в O(1).
                                                                                        +2
                                                                                        Нелюблю аппл, но помню как хлопал в ладоши при подключении к клиенту пирса (файлообменник в Новосибе) с маковского Леонардо (или как-там) клиента, который сначала подключался, показывал чатик и позволял уже формировать запросы на поиск файлов, а в фоне отрисовывал всю чепуху с 30к пользователей онлайн… На старом компе под виндовым DC++ это занимало минуту, на новом — секунд 15… Даже оптимизировать ничего не надо, просто ненужную задачу выбросили в фон и нехай там хоть по 5 минут думает.
                                                                                          +2

                                                                                          Или снимаешь галочку отображения списка клиентов в виндовом DC клиенте и получаешь тот же результат. При количестве пользователей в десятки тысяч этот список все равно смысла не имеет. Это не местечковый хаб с чатиком из начала 2000х, не нужен там этот список, там большая часть не люди, а приставки к ТВ.
                                                                                          Я ещё и чат отключал. Запуск приложения и подключение к хабу — секунда, ну может две.

                                                                                          0
                                                                                          А в vscode как на этом же файле? Это ведь vscode сейчас как раз модно и молодежно.
                                                                                            0
                                                                                            Лучше чем Sublime (возможно от версии зависит). У меня саблим долго грузил и падал на файле 131МБ, а vscode свободно открыл (предупредил о возможных тормозах и предложил отключить подсветку, я не стал этого делать и так норм работает, только памяти выжирает не мало) и в отличие от n++ сворачивал и разворачивал огромные ветки/узды без особых тормозов (в n++ они были минутами).
                                                                                            0
                                                                                            Невероятно, но факт. МС 20 лет (!), начиная с Windows 98 заявляет, что-де «переписали большую часть кода с нуля на ассемблере» и т.д. и т.п. Но с каждым разом «переписанная» система становится всё больше, а детские глюки как были, так и остаются.
                                                                                              0
                                                                                              Невероятно, но факт. МС 20 лет (!), начиная с Windows 98 заявляет, что-де «переписали большую часть кода с нуля на ассемблере» и т.д. и т.п.
                                                                                              Где? Я хочу почитать про такое.
                                                                                                0
                                                                                                Точно помню, что в те времена читал такое в журналах.
                                                                                                0
                                                                                                никогда они такого не говорили.
                                                                                                9x до самого своего упора, до ME, была допиленной 95 виндой на которую в 98 накатили IE4… да и закопали её потому что «переписывать» было себе дороже
                                                                                                  0
                                                                                                  Ну, я и сам так считаю и спорить не буду. Но точно помню слова про переписанный код, ассемблер, рост производительности и всё такое.
                                                                                              +9
                                                                                              нет не 1$, а блин 1$ + стоимость нового телефона за XYZKRE фантиков, потому что на старом это не работает.
                                                                                                +3

                                                                                                Именно так. Лично мне пришлось пару лет назад купить новый телефон, потому, что полностью устраивающий меня galaxy s2 открывал сообщение в скайпе за 30 секунд. К слову, прямо сейчас при наборе этого сообщения и пришедший ему на смену s6 подтормаживает. Неужто разрабы хабра тоже вирусом поражены?

                                                                                                  +5
                                                                                                  Редкие посты получают 1000+ комментариев.
                                                                                                    0
                                                                                                    1000 комментов, каждый в среднем по 300 символов. Сколько это? 300 килобайт?
                                                                                                      0
                                                                                                      Килобайты особо непричём, скорее дело в количестве Dom нод и т. п.
                                                                                                        0
                                                                                                        600. UTF-8 же.
                                                                                                          0
                                                                                                          Способ повесить ваш Chrome на минуту-полторы, если у вас x86:

                                                                                                          1. Нажмите на этой странице Ctrl+U
                                                                                                          2. Нажмите Ctrl+A на открывшейся вкладке
                                                                                                          3. Кликните по выделенному тексту правой кнопкой мыши в любом месте
                                                                                                          4. <>
                                                                                                          5. <>
                                                                                                          6. <>
                                                                                                          7. Снимайте процесс, если надоело ждать.
                                                                                                            0
                                                                                                            У меня Firefox и он не подвесился, хотя реагировал не сразу (сотни миллисекунд).
                                                                                                      0
                                                                                                      У хабра вроде есть приложение, где (наверное) можно хорошо оптимизировать отображение только нужной информации, для плавности.
                                                                                                    +21
                                                                                                    А кто сказал, что сделать хорошее, быстрое и надежное приложение обязательно очень долго и очень дорого?
                                                                                                    Вот тот же Web. Да, если каждый раз с нуля переписывать все эти библиотеки и фреймворки, то конечно. Только нужны ли они на 99% сайтов? Веб — это информация, текст, таблицы, картинки. Для этого всего вообще не нужен ни js, ни всякие библиотеки/фреймворки. уберите бессмысленное и бесполезное украшательство — и веб начнет летать на самых убогих компьютерах.
                                                                                                    А там, где они нужны, как правило, хватило бы ресурсов и для написания «с нуля». Но незачем, ибо пипл и так хавает.
                                                                                                      +35
                                                                                                      обычно люди которые так говорят, не занимались веб разработкой. Такие иллюзии достаточно быстро ломаются об реальность на больших проектах.
                                                                                                        +2
                                                                                                        Реальность состоит в том, что никто не хочет и не будет переделывать всё с нуля на больших проектах даже если это спасёт планету от метеорита. Ещё реальность состоит в том, что с первого раза может получиться только случайно, а в большом проекте — никогда.
                                                                                                          +1
                                                                                                          Ну, почему. Иногда переделывают. Это занимает от нескольких месяцев до нескольких лет, в зависимости от сложности и количества разработчиков. Скажем, потому что поддерживать сайт на XSLT и других древних технологиях уже нет смысла — проще переписать. Естественно, не обходится без багов (никто не совершенен), а к моменту что-то неизбежно уже устареет.
                                                                                                          0
                                                                                                          Причем тут «хочет, не хочет».
                                                                                                          Кто за это платит? По своему желанию переделываются только пет-проекты.
                                                                                                          В случае больших проектов, переделать все это далеко не копейки.
                                                                                                          +15
                                                                                                          Я никогда не работал в больших корпорациях, поэтому хотелось бы узнать, почему, например, когда я открываю Facebook.com как неавторизованный пользователь, страница занимает 6.16 MB и браузер отправляет 65 запросов? Наверное, дело в том, что форма регистрации использует AJAX-запросы и там всё «очень сложно»?! Ну, достаточно открыть страницу авторизации с «обычной» формой и полюбоваться «оптимизацией» — 3.75 MB и 37 запросов. Также, например, «оптимизирована» и главная страница Twitter.com — никаких форм с AJAX-запросами, однако размеры страницы составляет 2.41 MB, и браузер отправляет 18 запросов.

                                                                                                          Забавно, что даже при редактировании файла на Github.com страница весит
                                                                                                          лишь 1.63 MB (а там ведь подсветка кода, AJAX-запросы, живой поиск, предпросмотр, и другие полезные функции).
                                                                                                            +18

                                                                                                            «Вы ничего не понимаете, веб-программирование — это крайне очень супер сложно и вообще сперва добейся (закончи месячные курсы фулл-стека на пайтоне)».

                                                                                                              +3
                                                                                                              Представьте сколько аналитики, поведенческих метрик и рекламы с вас собирают facebook и twitter.
                                                                                                              Ну и конкретно на facebook большинство запросов это статика. Как прикажите картинки то грузить?
                                                                                                                +18
                                                                                                                На странице авторизации Facebook загружаются 6 картинок: два спрайта и 4 однопиксельных изображений. Общий размер картинок: 33.76 килобайт, когда страница занимает 3.75 мегабайт и это только для того чтобы отображать форму с двумя полями и одной кнопкой.

                                                                                                                Насчёт аналитики — даже Google Analytics и Яндекс.Метрика с Вебвизором вместе взятых не занимают больше 250 KB. Тут проблема не в аналитике, а в том, что разработчики банально не используют условные загрузки. По моему мнению, незачем загружать стили/скрипты комментариев, чата, списка друзей, редактирование профиля и других функций недоступны неавторизованных пользователей. Но, возможно это лишь мои иллюзии, ведь я не работал в крупных корпорациях.
                                                                                                                  0
                                                                                                                  Ну как же зачем?! Прогреть кэши перед входом пользователя на основной сайт, а не форму авторизации. Да, на одну страницу это слишком жирно, но зато после авторизации пользователь уже не будет ждать пока все скрипты загрузятся, особенно с медленным инетом, а сразу начнет поглощать контент.
                                                                                                                    +3
                                                                                                                    А Вы точно веб-разработчик? Даже если Вы правы насчёт этой теории, это, мягко говоря, неправильно. Не говоря уже о том, что после авторизации, страница «нагревается» до 42 MB.
                                                                                                                    Заголовок спойлера

                                                                                                                      0
                                                                                                                      Почему это неправильно? Если для ФБ ценны в первую очередь те, кто пойдет авторизироваться или регистрироваться, то логично сделать удобнее именно им.

                                                                                                                      А то, что там после загрузки еще больше, ни о чем не говорит. Вполне вероятно, что на странице логика грузятся только те библиотеки, которые делают изначальное отображение интерфейса и общие для всех пользователей. А после авторизации уже происходит фактические наполнение данными, но пользователь сразу видит уже какой-то каркас интерфейса.
                                                                                                                        –1
                                                                                                                        Если пользователь РЕШИЛ зарегестрироваться, то его не остановят мегабайты первой странички. Может, в первый раз отпугнёт и он передумает но через день-два-неделю он обязательно вернётся и зарегистрируется.
                                                                                                                        К сожалению, сам на мобильном интернете очень многих постов и картинок просто не увидел — тупо не дождался их загрузки, дольше 10 секунд загрузки — это уже бесполезная трата времени и вещь уходит куда-то далеко в бесконечную ленту событий, возврат к которой в будущем маловероятен.
                                                                                                                          +2
                                                                                                                          Неправильно, по крайней мере потому, что нужно уважать пользователей и помнить, что не у всех топовые устройства и высокоскоростной + безлимитный интернет. Правильно, когда нужное загружается «при необходимости», а не по принципу «а вдруг пользователь захочет каждую минуту загрузить новый аватар, редактировать профиль, отправить сотни эмодзи в чате, сделать селфи, и многое другое, причём всё сразу».

                                                                                                                          Вы предполагаете, что разработчики заранее кэшируют данные, а я не думаю, что они отличаются от тех, кто подключают jQuery на всех страницах сайтах, когда данная библиотека будет использована только на странице контактов, и то, чтобы анимировать одну кнопку, если пользователь открыл страницу 29 февраля в полночь. Во-первых, если бы они заботились об активных пользователях, они бы использовали условные загрузки по крайне мере после авторизации. Во-вторых, они подключают мегабайтные скрипты на всех страницах. В-третьих, пару мегабайт до авторизации лишь «цветочки» по сравнению, с тем, что происходит после. Если бы Вы проверили Вашу «теорию» о кэшировании, то заметили бы, что после авторизации сайт совсем «не летает», даже если все скрипты загружаются из кэша. Он и не будет, ведь это не SPA, и мегабайтные скрипты выполняются каждый раз, когда пользователь переходит на другую страницу.

                                                                                                                          Facebook и Twitter лишь примеры, но они далеко не единственные кто не допускают, что пользователь не будет использовать даже 10% функционала. Посмотрите, сколько ненужных стилей, скриптов и медиа файлов загружаются на веб-сайтах; какие права требуют простые приложения; какие спецэффекты используются, дабы рассказать какие «мы современные»; сколько шрифтов подключаются лишь, чтобы «показать красивое название сайта». Практически все с каждым днём «улучшают» свои программы и сайты, но, к сожалению, это происходит только в пресс-релизах.

                                                                                                                          Напоследок, хотелось бы напомнить, что даже js-файл размером в 1 MB это довольно много для сайта, где пользователи пишут и читают обычные посты. И, тем не менее, Вы хотите оправдать разработчиков, которые подключают десятки мегабайт JavaScript. Боюсь, я не могу согласиться с Вами, поэтому, прошу Вас, не вздумайте переходить на сторону зла!
                                                                                                                            0
                                                                                                                            Я напомню, что Фейсбук непосредственно заинтересован, чтобы им пользовалось как можно больше людей и не будет специально делать так, чтобы ухудшить динамику регистраций или логинов.
                                                                                                                            Еще напомню, что эта компания стоит сотни миллиардов и каждый день ее сервисом пользуется больше миллиарда человек и этого бы не было, если бы они разгильдяйски относились к таким важным элементам, как главная страница сайта.

                                                                                                                            С вашей стороны очень самонадеянно считать что вы знаете лучше, как надо делать и что решение сделать именно такой механизм работы страницы авторизации у Фейсбука продиктован ленью или некомпетентностью разработчиков.

                                                                                                                            У них есть огромное количество данных о том, что происходит на сервисе на каждом этапе его работы, данные о сотнях миллионах пользователей (если говорить о веб версии). Равно как и есть возможность протестировать и сравнить множество альтернативных вариантов.

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

                                                                                                                            Единственный сценарий, при котором такой подход может навредить, это если посетитель не будет авторизироваться, а просто зайдет на страницу. В этом случае загрузятся лишние мегабайты.

                                                                                                                            Но сервис вполне логично ставит интересы таких посетителей ниже тех, кто авторизацию пройдет.
                                                                                                                              +4
                                                                                                                              Еще напомню, что эта компания стоит сотни миллиардов и каждый день ее сервисом пользуется больше миллиарда человек и этого бы не было, если бы они разгильдяйски относились к таким важным элементам, как главная страница сайта.

                                                                                                                              Наивное утверждение. Сервис настолько огромен и популярен, что у существующих пользователей просто-напросто нет выбора (нет аналогов, куда перейти, ведь все друзья в сидят в фейсбуке). А с новыми пользователями то же самое — в мелкую соцсеть типа MySpace идти нет смысла, так как там почти никого нет.

                                                                                                                              А если вы почитаете, что люди пишут про скорость работы (что веб версии, что мобильного приложения в том же Google Play), то вы увидите, что негативных отзывов гораздо больше, чем позитивных (я правда читал только русскоязычные комментарии, но можно начать хотя бы с России как частного случая). Вы только вспомните: мобильное приложение фейсбука стало настолько тяжёлым, что из него выпилили мессенджер и выпустили отдельным приложением! А потом ещё выпустили Facebook Lite, к слову…
                                                                                                                                0
                                                                                                                                Хотелось бы добавить, что лично я не считаю, что огромное количество денег и пользователей это показатель профессионализма. Скорее это говорит о том, что они хорошие бизнесмены и маркетологи.

                                                                                                                                Действительно, сверхпопулярные компании могут позволить себе очень многое. И если они изначально работают над привлечением новых пользователей, то став популярными, чаще всего в первую очередь они думают, как извлечь максимальную прибыль. Как монополисты они уверены, что пользователи никуда не убегут, а значит, они могут творить любую дичь. Правда, некоторые из них (например, IE, ICQ, MySpace, Yahoo) поплатились за это.
                                                                                                                                  0
                                                                                                                                  А что в своё время натворил MySpace? Я туда заходил 2-3 года назад и был в полном восторге — и от дизайна, и от того, насколько сайт был шустрым и минималистичным.
                                                                                                                                    +2
                                                                                                                                    Это сейчас он «шустрый и реалистичный». Потому что у разработчиков нет ресурсов, чтобы рюшечек навешать. А когда Facebook «взлетел» примерно 10 лет назад — всё было наоборот.

                                                                                                                                    Дорога ложка к обеду. Очень хороший пример тут — OS/2 и Windows. Когда в 1992м вышла OS/2, которая требовала 8MB, а на 4MB еле «шевелилась», то народ выбрал вышедшую тогда же Windows 3.1, которая сносно работала на 1MB, а на 2MB «летала». IBM вложила кучу ресурсов и в 1994м выпустил OS/2 Warp, которая более-менее работала на 2MB, а на 4MB — так вообще хорошо. Про неё начали потихоньку говорить, но через полгода — вышла Windows 95, которая требовала уже 4MB, а для приличной работы — 8MB… казалось бы должен был быть провал? Но нет: за 3 года ситуация с памятью изменилась и те 8MB, которые в 1992м казались чем-то запредельным в 1995м уже перешли в категорию «дорого, но терпимо»… а зато у Windows95 была куча программ, которых у OS/2 не было…
                                                                                                                                +1
                                                                                                                                Я напомню, что Фейсбук непосредственно заинтересован, чтобы им пользовалось как можно больше людей и не будет специально делать так, чтобы ухудшить динамику регистраций или логинов.
                                                                                                                                Еще напомню, что эта компания стоит сотни миллиардов и каждый день ее сервисом пользуется больше миллиарда человек и этого бы не было, если бы они разгильдяйски относились к таким важным элементам, как главная страница сайта.

                                                                                                                                Я не встречал ни одного человека, который бы сказал что ему нравится дизайн и функциональность фейсбука. Ни в России, ни в Европе. Пользуются им все просто потому что им уже пользуются все и чтобы с него уйти нужно, во-первых, найти куда, а так как все пользуются ФБ, то адекватно развитого ничего и нет, во-вторых, переманить туда всех нужных знакомых, что тоже титанический труд, человеку проще ничего не менять и плеваться чем напрягать мозг и совершать какие-то действия, а в-третьих, нужно придумать что делать с новыми знакомыми и всякими группами которые тоже будут по умолчанию в ФБ. Так что пока этим поделием в принципе можно будет пользоваться — им будут пользоваться все. Это никак не говорит о том что они знают что делают. Более того я знаю больше одного человека, которые из-за всего этого бреда в ФБ отказались от него несмотря на все перечисленные пункты.
                                                                                                                                  +1
                                                                                                                                  На самом деле вы оба правы. Facebook, конечно, знает что делает, но… не сегодняшний Facebook. Хочу напомнить, что Facebook — далеко не первая социальная сеть, до него были MySpace, Orkut и другие. А знаете что с ними произошло? Их обошёл маленький и шустрый (в те времена) Facebook. А потом… потом менеджеры в Facebook выяснили что «рюшечки» привлекают пользователей! Процесс идёт по накатанной схеме. В результате в какой-то момент вы имеете кучу пользователей, которых привлекли на начальном этапе (и ненавидящих современный Facebook), пользователей которых «зачинатели» привели и тех, кто фанатеет от рюшечек и кому пофигу что они тормозят. Тут вы имеете максимальную капитализацию, аудиторию и прочее. Но эта ситуация неустойчива: в какой-то момент, после очередного раунда «добавления рюшечек» всё начинает тормозить настолько, что люди начинают уходить. И если этого не осознать и добавить «рюшечек» ещё — то всё начнёт рассыпаться: вначале уйдут первые (ценившие скорость), потом вторые (так как ушли первые), а потом и ценившие «рюшечки» не захотят в «пустом доме» жить. Но Facebook'у пока удаётся балансировать «на грани»: периодически он всё-таки занимается оптимизацией своих страниц, в результате такого коллапса, как, скажем, у Orkut'а не происходит.
                                                                                                                        –2
                                                                                                                        Крупные корпорации это всегда бюрократия. Не исключено, что какие-нибудь маркетологи решили, что именно страница логина должна принять на себя удар по перфомансу и сразу подгрузить всё, что нужно юзеру, чтобы после логина он на доли секунды быстрее увидел свою вожделенную ленту новостей.
                                                                                                                          0
                                                                                                                          Можно ещё вспомнить «модемные» времена и Мейл.ру, чья страничка весила килобайт 50. И при этом работала, письма писались, отправлялись. Понятно, что сейчас там и форматирование и всякая живая загрузка. Но, страница выросла мегабайт до 5, если не больше, то раз в 100. Но удобство (как ни измеряй;) и скорость в 100 раз не выросли.
                                                                                                                        +1
                                                                                                                        Че-то вы загнули… 1.1МБ на странице авторизации ФБ
                                                                                                                        Заголовок спойлера
                                                                                                                        image