И всё равно этот хром сожрёт все 8Гб и будет лагать.
05.03.2019, 01:43
Вот только тогда за этим ужатым полигоном не было вагона костылей, а всего лишь тележка.
Если говорить об низкоуровневой оптимизации, о числодробилках, то компилятор превосходит человека. Он способен делать много крутых вещей, например, менять порядок инструкций, чтобы оптимально заполнить конвейер (указав при помощи флагов семейство процессоров, на котором предполагается гонять, то можно еще чуть лучше). Это про Intel Compiler, но обычный gcc не сильно хуже.
Ворд тормозит из-за сотни слоев абстракции, кома-хуема, синхронизаций и еще какой-нибудь хуйни. Каких-то прям тяжких вычислений там не много.
Ворд тормозит из-за сотни слоев абстракции, кома-хуема, синхронизаций и еще какой-нибудь хуйни. Каких-то прям тяжких вычислений там не много.
проблема не в контенте, а в обвесе вокруг него ради удобства разработчиков.
Без удобства разработчиков не будет софта, потому что у разработчиков есть предел понимания системы, и не пряча абстракцию не выйдет сделать ничего.
P.S.
Абстракции это нормально, даже хорошо. Абстракция это как модель, отражает только нужные нам качества чего-то. Их ограниченное количество и все нужные, и это дает настоящий контроль. Если вы управляете автомобилем то вы управляете с помощью руля и педалей. Где-то там работает двигатель по своему циклу карно, что-то подсчитывает и контролирует бортовой компьютер, и где-то датчик в бензобаке ждет своего часа. Вы смотрите на панель и крутите руль, а не контролируете каждое колесо отдельным рычагом, наблюдая работу двигателя через прозрачный кожух в прозрачных цилиндрах и периодически на ходу опускаете щуп в бензобак.
Вам все это не нужно, да это даст больший контроль (на самом деле нет), но это не нужный в данный момент контроль, он только мешает, забирает время, отвлекает, размывает фокус, и котролируя каждое колесо вы меньше внимания сможете потратить на дорогу. Контроль потребуется когда вы услышите странный стук а потом машина заглохнет. Вот тогда вы откроете капот. Или потащите автомобиль в автосервис.
Да мы пользователи. Пользователи процессора, файловой системы, пользователи библиотек и third-party закрытых инструментов, пользователи API внешних сервисов. Мы пользователи черных ящиков. Эти ящики вокруг нас. При разработке мы фокусируемся на том что нам нужно сделать, при этом «пользуясь» кучей инструментов о которых мы знаем крайне мало, только то что нам нужно. И если мы будем заглядывать постоянно к каждой машине под капот, просто чтобы сохранить имитацию (да именно имитацию) контроля — мы не сможем заниматься основной задачей. Мы заглядываем под капот, вскрываем ящик только тогда когда понимаем что проблема именно в этом ящике. Или не вскрываем а меняем. И это нормально. Потому что мы знаем что вот этот черный ящик с надписью «процессор» выполняет то-то и то-то, мы знаем что он делает, нам не нужно знать как, и тогда черный ящик можно спокойно заменить на другой с тем же набором свойств. Сервис на другой. Библиотеку обновить. Это отлично, это дает гибкость и стабильность. И все благодаря абстракциям.
А полноценно контролировали и софт и железо только в 50-е, когда еще и разделения толком не было и софт писался под конретный экземпляр компьютера. Вот там контроль. Вот там постоянно открытый капот. Вот там заточка кода под железо а железа под код. Вот там знание компьютера до каждого резистора и понимание каждого байта и каждого сигнала. Вот только это совсем не эффективно и не надежно, и замена «винчестера» (не говоря уже о «процессоре») могла превратить весь софт в ненужный хлам.
P.S.
Абстракции это нормально, даже хорошо. Абстракция это как модель, отражает только нужные нам качества чего-то. Их ограниченное количество и все нужные, и это дает настоящий контроль. Если вы управляете автомобилем то вы управляете с помощью руля и педалей. Где-то там работает двигатель по своему циклу карно, что-то подсчитывает и контролирует бортовой компьютер, и где-то датчик в бензобаке ждет своего часа. Вы смотрите на панель и крутите руль, а не контролируете каждое колесо отдельным рычагом, наблюдая работу двигателя через прозрачный кожух в прозрачных цилиндрах и периодически на ходу опускаете щуп в бензобак.
Вам все это не нужно, да это даст больший контроль (на самом деле нет), но это не нужный в данный момент контроль, он только мешает, забирает время, отвлекает, размывает фокус, и котролируя каждое колесо вы меньше внимания сможете потратить на дорогу. Контроль потребуется когда вы услышите странный стук а потом машина заглохнет. Вот тогда вы откроете капот. Или потащите автомобиль в автосервис.
Да мы пользователи. Пользователи процессора, файловой системы, пользователи библиотек и third-party закрытых инструментов, пользователи API внешних сервисов. Мы пользователи черных ящиков. Эти ящики вокруг нас. При разработке мы фокусируемся на том что нам нужно сделать, при этом «пользуясь» кучей инструментов о которых мы знаем крайне мало, только то что нам нужно. И если мы будем заглядывать постоянно к каждой машине под капот, просто чтобы сохранить имитацию (да именно имитацию) контроля — мы не сможем заниматься основной задачей. Мы заглядываем под капот, вскрываем ящик только тогда когда понимаем что проблема именно в этом ящике. Или не вскрываем а меняем. И это нормально. Потому что мы знаем что вот этот черный ящик с надписью «процессор» выполняет то-то и то-то, мы знаем что он делает, нам не нужно знать как, и тогда черный ящик можно спокойно заменить на другой с тем же набором свойств. Сервис на другой. Библиотеку обновить. Это отлично, это дает гибкость и стабильность. И все благодаря абстракциям.
А полноценно контролировали и софт и железо только в 50-е, когда еще и разделения толком не было и софт писался под конретный экземпляр компьютера. Вот там контроль. Вот там постоянно открытый капот. Вот там заточка кода под железо а железа под код. Вот там знание компьютера до каждого резистора и понимание каждого байта и каждого сигнала. Вот только это совсем не эффективно и не надежно, и замена «винчестера» (не говоря уже о «процессоре») могла превратить весь софт в ненужный хлам.
Это правильное мнение. Попробуйте написать веб-сервер, который отдаст страничку, на ассемблере. Без ОС, потому что ОС - тоже абстракция. Сколько времени и сил потребуется, насколько больно будет отлаживать и улучшать?
Но тут две вещи.
1) Всему есть предел, баланс между абстрактностью и гибкостью/производительностью/жирностью.
2) Все абстракции текут. Этот термин обозначает, что абстракция не полностью скрывает нижележащее, есть косвенные эффекты, которые нельзя игнорировать в определенных случаях.
Но тут две вещи.
1) Всему есть предел, баланс между абстрактностью и гибкостью/производительностью/жирностью.
2) Все абстракции текут. Этот термин обозначает, что абстракция не полностью скрывает нижележащее, есть косвенные эффекты, которые нельзя игнорировать в определенных случаях.
эх, свернули мы совсем не туда, и даже знаем где, но уже поздно(
Банальная оптимизация процесса разработки под актуальное железо.
Можно делать все как и раньше, только тогда бы индустрия сейчас бы в развитии оставала от современного уровня лет на 10.
Оптимизация это сложный затратный процесс который очень плохо конвертируется в прибыль и для большинства компаний невозможен.
Можно делать все как и раньше, только тогда бы индустрия сейчас бы в развитии оставала от современного уровня лет на 10.
Оптимизация это сложный затратный процесс который очень плохо конвертируется в прибыль и для большинства компаний невозможен.
История с веб-сайтами и т.п. это история колосса на глиняных ножках, который однажды был маленьким и ножек ему хватало, пока на него не прихуячили тонну свистоперделок, и к которому энтузиасты в один прекрасный момент подогнали вертолет, и с тех пор пиздец только увеличивается с числом хлама на теле колосса и количеством вертолетов.
Что характерно, вертолеты колосса поднять не могут, и он так и шагает на своих ножках.
Так и живем, разраб говнософта для пизнеса на фреймфорках((0((0(0(((
Что характерно, вертолеты колосса поднять не могут, и он так и шагает на своих ножках.
Так и живем, разраб говнософта для пизнеса на фреймфорках((0((0(0(((
Просто все классные инструменты разработчики оставили себе. Посмотрите только на уровень отзывчивости каких-нибудь github/stackoverflow, где количество посещений не меньше твиттера. Полусекундный подлаг IDE которыя не может мгновенно выдать fuzzy-поиск на миллионах строк кода вызывает негодование и посты про тормознутую джаву.
Ну и уровень софта немного поменялся. Раньше сайт был просто наобором статей, а теперь в нем триллионы всевозможных интеграций (чтобы можно зайти по своему гугловому акканту, а не регистрироваться на каждом сайте отдельно), финтишлюшек (ajax-подгрузка данных без обновления страницы), всякие пуши/нотификаторы, ну и прочая дребедень, которая давно воспринимается как должное. Все это жрет кило, а иногда и мегабайты. И лишние полсекунды на загрузку страницы обычно стоят того, что можно переключиться в другую вкладку, а потом подсветится "ваш комментарий на джое обосрали. Хотите перекинуться с обидчиком?".
Ну и уровень софта немного поменялся. Раньше сайт был просто наобором статей, а теперь в нем триллионы всевозможных интеграций (чтобы можно зайти по своему гугловому акканту, а не регистрироваться на каждом сайте отдельно), финтишлюшек (ajax-подгрузка данных без обновления страницы), всякие пуши/нотификаторы, ну и прочая дребедень, которая давно воспринимается как должное. Все это жрет кило, а иногда и мегабайты. И лишние полсекунды на загрузку страницы обычно стоят того, что можно переключиться в другую вкладку, а потом подсветится "ваш комментарий на джое обосрали. Хотите перекинуться с обидчиком?".
Тот же вход по гуглу требует поддержки на стороне бэкенда и имеет оверхед один раз. Затем токены или иная поебота (в зависимости от имплементации) лежит в куках и кушать не просит. Чтоб аутентифицировать пользователя не надо даже лазить в базу, достаточно сравнить хэши.
> ajax-подгрузка данных без обновления страницы
И вот тут мы вступаем на скользкую тропу. Где-то надо, где-то не надо, а где-то надо в ограниченном объеме. Пример - хабр. Добавление комментария происходит с помощью ajax, и это правильно. Все, это почти весь ajax-функционал, который там нужен. А потом эти уебки сломали мобильную версию, которая теперь SPA. Вместо того, чтобы просто загрузить страницу, сначала загружается пустая страница, потом подгружаются статьи, потом подгружается информация из аккаунта, если ты вошел, и статьям проставляется количество новых комментариев и появляется кнопка "по подписке". Нажимаешь на нее, и снова идет ебаная подгрузка. Вот скажите, это было настолько охуенно важно, что теперь статьи грузятся без перезагрузки страницы, подтягивая даные ajax'ом?
> ajax-подгрузка данных без обновления страницы
И вот тут мы вступаем на скользкую тропу. Где-то надо, где-то не надо, а где-то надо в ограниченном объеме. Пример - хабр. Добавление комментария происходит с помощью ajax, и это правильно. Все, это почти весь ajax-функционал, который там нужен. А потом эти уебки сломали мобильную версию, которая теперь SPA. Вместо того, чтобы просто загрузить страницу, сначала загружается пустая страница, потом подгружаются статьи, потом подгружается информация из аккаунта, если ты вошел, и статьям проставляется количество новых комментариев и появляется кнопка "по подписке". Нажимаешь на нее, и снова идет ебаная подгрузка. Вот скажите, это было настолько охуенно важно, что теперь статьи грузятся без перезагрузки страницы, подтягивая даные ajax'ом?
Где-то начали рыдать разработчики игр под современные консоли. Хочется вспомнить банальный пример, когда три игры (Battlefield 4, DA: Inquisition и Mass Effect Andromeda) на одном и том же движке (Frostbite 3.0) ведут себя сравнительно хорошо на приставках (причём две (B4 и DA:I) из них хоть и на минималках, но работают даже на PS3), но работают через жопу на существенно более мощном ПК.
Это все очень притянуто за уши. Что значит работает хорошо? Если рассматривать графику внимательно, можно даже из видяшек на ютубе, то можно заметить что консоли очень нехило режут графические эффекты. Метро кладет на лопатки современные компы но хорошо работает на консолях, почему? Потому что там половина наворотов вообще выключено а картинка мыльновата. Апекс на х360 (каким бы позорищем ни была сама консоль) может упасть даже ниже 720p разрешения, и так далее.
Мы видим ту же самую петрушку что и на ПК - на консолях по настоящему хорошую оптимизацию могут позволить только гиганты типа рокстар (рдр2 смотрится просто охуенно), эксклюзивы от сони (анч4 в картинке так же великолепен), а остальные предоставляют то или иное мыльцо разной степени паршивости.
Близзард дает хорошую оптимизацию, овервоч хорошо летает даже на калькуляторах. И по большому счету список можно заканчивать, 95% индустрии делает ее условно паршиво. Не потому что им в падлу, а просто это не выгодно и слишком ресурсозатратно. Добавлять еще полгода разработки и ничего за это не заработать это такое себе.
Мы видим ту же самую петрушку что и на ПК - на консолях по настоящему хорошую оптимизацию могут позволить только гиганты типа рокстар (рдр2 смотрится просто охуенно), эксклюзивы от сони (анч4 в картинке так же великолепен), а остальные предоставляют то или иное мыльцо разной степени паршивости.
Близзард дает хорошую оптимизацию, овервоч хорошо летает даже на калькуляторах. И по большому счету список можно заканчивать, 95% индустрии делает ее условно паршиво. Не потому что им в падлу, а просто это не выгодно и слишком ресурсозатратно. Добавлять еще полгода разработки и ничего за это не заработать это такое себе.
Во-первых, для победителей специальной олимпиады - я специально указал, что на консолях старого поколения игры работали на минималках, видимо люди читают жопой. Но игры работали. А если брать те же BF4, DA:I и ME:A, работающие на одном и том же железе выпущенном в далёком 2013 году (та же PS4), то игры работали. Но та же ME:A на ПК могла выдавать настолько жуткие графические глюки, что игра становилась совершенно не проходимой на видюхе, которая прекрасно отрабатывала BF4 и DA:I. При одном и том же графическом движке. Больше оперативки, круче проц, GPU...
Но говоря об оптимизации - игры оптимизирует и та же Юбисофт (Far Cry 4 выглядит вполне прилично даже на PS3/X360, за AC: BF ничего не скажу, не играл, но past/current gen используют один и тот же движок). А ещё Infinity Ward и Treyarch и многие другие. И один и тот же движок оказывается весьма хорошо масштабируемым. Т.е. проблемы не в "окупаемости", а в тупой рукожопости разработчиков. Те же Naughty Dogs создавая свои игры много чего из инструментов разработки создавали сами с нуля. И они одни из первых в индустрии реализовали хитрожопые костыли, благодаря которым персонаж Анчартеда СНЯЛ с себя костюм прямо в кадре.
Просто у кого-то руки под кривой хуй заточены, да и с тем плохо справляются, а кто-то и из старого железа умудряется выжать ещё пару процентов потенциала.
Но говоря об оптимизации - игры оптимизирует и та же Юбисофт (Far Cry 4 выглядит вполне прилично даже на PS3/X360, за AC: BF ничего не скажу, не играл, но past/current gen используют один и тот же движок). А ещё Infinity Ward и Treyarch и многие другие. И один и тот же движок оказывается весьма хорошо масштабируемым. Т.е. проблемы не в "окупаемости", а в тупой рукожопости разработчиков. Те же Naughty Dogs создавая свои игры много чего из инструментов разработки создавали сами с нуля. И они одни из первых в индустрии реализовали хитрожопые костыли, благодаря которым персонаж Анчартеда СНЯЛ с себя костюм прямо в кадре.
Просто у кого-то руки под кривой хуй заточены, да и с тем плохо справляются, а кто-то и из старого железа умудряется выжать ещё пару процентов потенциала.
> ME:A
Вряд ли можно заметить артефакты в игре, в которую никто не играет
> Но игры работали.
у меня так старкрафт второй на 8600gt 256mb ram "работал". Смотреть без слез на геймлей в 15фпс с просадками до 5 сейчас нельзя. А в 2010 играл, альтернатив особо не было.
Что касается вопроса, объяснение с потолка: в консоли обычно идут процессоры от АМД, тогда как в десктопах почти всегда интелы. Дальше, хотя процессоры и обещают "х86", по факту у них разные множества команд, которые совпадают только в том, что описанно в стандарте. Это значит, что все "улучшайзеры" у каждой фирмы свои. Например, SSE4.1 vs SSE4a, или например AVX команда, которая занимает 2 такта на АМДшном проце, и 1 на интеловском. Если игра разрабатывается под амд, то от AVX в таком случае будет выгоднее отказаться, а на интеловском это даст соответствующую просадку относительно решения "делать на avx". Часть инструкций вообще может быть не реализована, тогда будет выполняться программный фоллбек. Как это влияет на производительность можно посмотреть на примере итаниума и х86 кода.
Это примеры с потолка, но примерно объясняют потенциальные причины. Ну и банальные зарезали графон. В сказки что "да на пк тот же графон" я не верю без пруфов, картинка идентичная натуральной это хорошо, но на натуральную тратится больше ресурсов.
Вряд ли можно заметить артефакты в игре, в которую никто не играет
> Но игры работали.
у меня так старкрафт второй на 8600gt 256mb ram "работал". Смотреть без слез на геймлей в 15фпс с просадками до 5 сейчас нельзя. А в 2010 играл, альтернатив особо не было.
Что касается вопроса, объяснение с потолка: в консоли обычно идут процессоры от АМД, тогда как в десктопах почти всегда интелы. Дальше, хотя процессоры и обещают "х86", по факту у них разные множества команд, которые совпадают только в том, что описанно в стандарте. Это значит, что все "улучшайзеры" у каждой фирмы свои. Например, SSE4.1 vs SSE4a, или например AVX команда, которая занимает 2 такта на АМДшном проце, и 1 на интеловском. Если игра разрабатывается под амд, то от AVX в таком случае будет выгоднее отказаться, а на интеловском это даст соответствующую просадку относительно решения "делать на avx". Часть инструкций вообще может быть не реализована, тогда будет выполняться программный фоллбек. Как это влияет на производительность можно посмотреть на примере итаниума и х86 кода.
Это примеры с потолка, но примерно объясняют потенциальные причины. Ну и банальные зарезали графон. В сказки что "да на пк тот же графон" я не верю без пруфов, картинка идентичная натуральной это хорошо, но на натуральную тратится больше ресурсов.
У меня жена играла во все части МЕ и ДА. Так что после Инквизиции играя в Андромеду на ровно том же движке и видя воду, вылетающую до облаков и перекрывающую собой буквально всё - это было весьма, кхм, обескураживающе. И это на ПКшечке. На консоли такой хуйни почему-то не происходит.
8600GT не далеко ускакала от 7600GT из минимальных системных требований для второго старкрафта. При этом стоит помнить, что "минимальные системные требования" это характеристики, при которых игра гарантированно запустится при минимальных графических графических настройках и минимальном поддерживаемом разрешении. При этом даже 30 ФПС никто не гарантирует - кое-как работает и заебись. Что у тебя и получилось.
Второй момент "в консоли идут процессора от АМД" - это касается только PS4/XONE. В предыдущем поколении (PS3/X360/Wii) рулили PowerPC камни, которые вообще RISC.
Третий момент - системные требования для той же Андромеды - для ПКшки требуется Intel Core i5 3570 или AMD FX-6350 (та-да-а-а-а, разработчики ПК версии учитывают особенности АДМшных процессоров и для ПК версии игры^_^) для минималочек и NVIDIA GTX 660 2GB или AMD Radeon 7850 2GB в качестве видюхи. PS4 отсасывает у этой конфигурации со заглотом. Но Андромеда работает на PS4 весьма прилично. Парадокс? Или чудеса оптимизации?
Покажи мне место в моих постах, где я утверждал, что графика на консолях и на ПК идентичны по качеству? Я русским по-белому написал, цитирую, "игры ведут себя сравнительно хорошо на приставках". Это и рядом не валяется с "охуенностью ПК-мастер-рейс".
8600GT не далеко ускакала от 7600GT из минимальных системных требований для второго старкрафта. При этом стоит помнить, что "минимальные системные требования" это характеристики, при которых игра гарантированно запустится при минимальных графических графических настройках и минимальном поддерживаемом разрешении. При этом даже 30 ФПС никто не гарантирует - кое-как работает и заебись. Что у тебя и получилось.
Второй момент "в консоли идут процессора от АМД" - это касается только PS4/XONE. В предыдущем поколении (PS3/X360/Wii) рулили PowerPC камни, которые вообще RISC.
Третий момент - системные требования для той же Андромеды - для ПКшки требуется Intel Core i5 3570 или AMD FX-6350 (та-да-а-а-а, разработчики ПК версии учитывают особенности АДМшных процессоров и для ПК версии игры^_^) для минималочек и NVIDIA GTX 660 2GB или AMD Radeon 7850 2GB в качестве видюхи. PS4 отсасывает у этой конфигурации со заглотом. Но Андромеда работает на PS4 весьма прилично. Парадокс? Или чудеса оптимизации?
Покажи мне место в моих постах, где я утверждал, что графика на консолях и на ПК идентичны по качеству? Я русским по-белому написал, цитирую, "игры ведут себя сравнительно хорошо на приставках". Это и рядом не валяется с "охуенностью ПК-мастер-рейс".
тут еще понемашь, в сравнение не оверграфонистые современные игры, а веб-страницы, которые сами по себе такой сложности иметь не должны. Диссонанс
Ну да, а за счет чего думаешь у нас шел этот бесконечный рост скорости работы браузеров начиная с выхода хрома? Не за оптимизацию кода, внезапно. А потому что они учились эффективно использовать имеющиеся новые мощности. Больше памяти, больше гигагерц, зато ява грузится еще быстрее. Плюс все хотят красивостей, чтобы все пердело и светилось, чтобы везде встроенные плееры, чтобы чатик был справа от стрима на твиче, чтобы в вк можно было превьюшки на ссылки прямо в чате видеть и так далее. Это все не на святом духе работает. Хотя и говнокода хватает понятно.
кто эти все, которые это хотят?
верните мне веб 1.0!
верните мне веб 1.0!
веб 2.0 не значит много памяти и гигагерцев. быдлокодеров поналезло просто, которые ради кнопочки тянут жыырные компоненты с десятками зависимостей, а чтоб тянуть - ставят ноду и тяжелые фреймворки. в итоге имеем практически пустой проект с 50 тысячами файлов, который отжирает у браузера 300-500 мб памяти на вкладку своим виртуальным домом и перерендеривающим реальный дом чуть ли не на каждое движение мышки
Бесконечный рост скорости браузеров, начиная с хрома? Как лагало, так и лаегает. А вот Opera Presto, помню, была весьма шустрой. И старт браузера, и отображение страниц.
А что тогда есть "научились более эффективно использовать новые мощности", как оптимизация? Ну или криво сформулированная фраза, я не понял.
А что тогда есть "научились более эффективно использовать новые мощности", как оптимизация? Ну или криво сформулированная фраза, я не понял.
А, ниже уже как раз скинули http://reactor.cc/post/3849026#comment17955270
в упрощеном виде. Win 98 делает практическе тоже самое что и WIN10 но почему Win98 пашет 233 intel на 128 мб а win 10 и 3 ггц с 8 Гб оперативки на SSD диске тупит. У меня всегда было ощущение что в софт заложен какой то троянский конь который умышленно тормозит вычисления вынуждая usera апгрейдить железо чтоб потом через год снова начать тупить и вынуждать к новой покупке. Скоро для запуска Chroma нужен будет комп 16 ядрами и 64 Гб оперативки а он всеравно будет тупить и долго запускаться
ну, хромиум сейчас активно оптимизируют. Тайлинг - хуяйлинг, оптимизация отрисовки на уровне рендера
Вспоминаются приснопамятные патчи для винды, закрывающие всякие бреши в ЦП, при этом, ясное дело, снижающие производительность. Но вот в новых ЦП брешей нет, поэтому купи новый проц чтоб он работал как старый до патчей винды. И да, про оптимизацию где-то было написано от имени девелопера: мне проще чтоб юзер купил себе ОЗУ. чем заплатить разрабу за оптимизон. Так и живём.
На новых ЦП бреши тоже есть, это часть архитектуры современных процессоров. Только она кое-как закрыта программной заплаткой ОС
что обидно - для 98% юзеров эти бреши и патчи нафиг не нужны, проблемы возникают только в довольно специфических задачах типа шифрования, когда можно другими процессами считывать незащищённые данные. но микрософту нужно прикрыть свой зад всех загоняя под одну гребёнку.
win10 слишком всё контроллирует и там всё на перекрёстных ссылках: открываешь папку - винда на каждый файл десятки операций производит, сопоставляет с программами, которыми его можно открыть, ищет все наборы иконок, проверяет кучу атрибутов допусков и доступов, всякие протоколы шифрования, пытается создать миниатюры, если их нет в кеше (а их как правило нет в кеше) даже если не стоит пункт "в виде миниатюр", кроме того, известные файлы начинают открываться на чтение для проверки их mime-типов - вдруг расширение неправильное, ну и так далее. В 95-98-2к винде всё работало напрямую, по кратчайшему пути, атрибуты доступов прописывались в самой файловой системе, а не перекрёстными ссылками на профили (в winNT/2k это можно было настроить - прописывать владельцев файлов и доступа, в т.ч. по сети, но это значительно тормозило систему, 10 тыс. "ничейных" файлов с сетевого Fat32 в тотал-коммандере загружались за пару секунд, а с NTFS с правами доступа по группе юзеров - до минуты).
Потому что дъявол в мелочах, и правило 80/20 тут работает как никогда. Видимо, уже забыты времена, когда комп уходящий ежемесячно в БСОД было нормой, что за драйвером на принтер нужно было обойти весь рынок, что в компе саунд бластер мог просто не определяться никак, что драйвера лазили друг другу в память и все ломали, что софт не умел работать на разрешении отличном от того, под который разарабтывался...
> Скоро для запуска Chroma нужен будет комп 16 ядрами и 64 Гб оперативки а он всеравно будет тупить и долго запускаться
Это к товарищам фронтендерам с их модными "всё есть JS". Я возможно кого-то удивлю. но сейчас большинство устанавливаемого софта ставит с собой маленький хром. Дискорд например, или слак, или скайп, и еще 100500 софтин, которые в прямом смысле ставят хром вместе с собой. Причем каждый будет ставить свой собственный, использовать взрослый хром или какую-то общую инсталляцию сделать они не могут.
> Скоро для запуска Chroma нужен будет комп 16 ядрами и 64 Гб оперативки а он всеравно будет тупить и долго запускаться
Это к товарищам фронтендерам с их модными "всё есть JS". Я возможно кого-то удивлю. но сейчас большинство устанавливаемого софта ставит с собой маленький хром. Дискорд например, или слак, или скайп, и еще 100500 софтин, которые в прямом смысле ставят хром вместе с собой. Причем каждый будет ставить свой собственный, использовать взрослый хром или какую-то общую инсталляцию сделать они не могут.
сейчас вроде 2019 год или как?
оу, ну извини, не 8 гигов, а 64
Я про то что на картинке указан 2018 год. Блять а стадо сразу заминусило.
Осенью на хабре был перевод длинного поста https://habr.com/ru/post/423889/
О том, куда катится современный софт, о том, что оптимизация не окупается, ну и всё такое прочее.
Довольно интересное чтение.
О том, куда катится современный софт, о том, что оптимизация не окупается, ну и всё такое прочее.
Довольно интересное чтение.
Это ведь не едниничный случай на странице, плюс посмотри сколько вложенных div, отъедающих ресурсы на обработку во имя великой цели - впарить рекламу в обход блокировщика даже если ты адблоком не пользуешься. Так что не "нагрузка в 11 элементов", а "нагрузка в 11 раз больше, чем была бы без подобной херни".
не забывай, что там под капотом реакт, ещё есть виртуальный дом, который почти постоянно заставляет перерендериваться реальный дом (как минимум - при наведении мышки на каждый из этих элементов). плюс овердохуя цсс-ок на много десятков или сотен тысяч правил, и при рендеринге каждого элемента страницы приходится пробегаться по всем этим правилам, сверяя селектор.
можно это как-то отключить нахер со стороны пользователя?
Отключить js.
А вот может мне кто-нибудь объяснить эту охуенную идею Virtual DOM? Т.е. операции с DOM при помощи браузера, который умные люди написали на C++, медленные, поэтому мы щас нахуярим эмуляцию DOM на JS, который интерпретируется браузером, а потом получим состояние реального дома, сверим, найдем diff (это все на JS), и потом выплюнем в браузер этот diff. Какого хуя это типо быстрее?
Изменение DOM приводит к повторному парсингу стилей, что исключает парадигмы "рекативного" и событийно-ориентированного просрамирования. К тому же, операции с DOM - происходят в одном потоке (в сторону более современной реализации движется только Mozilla).
VirtualDOM позволяет расчитать diff между текущим деревом и тем, которое будет создано. Часть операций могут обрабатываться многопоточно (хотя модель многопоточности в js - говно).
Имеем коллоса на глиняных ногах.
VirtualDOM позволяет расчитать diff между текущим деревом и тем, которое будет создано. Часть операций могут обрабатываться многопоточно (хотя модель многопоточности в js - говно).
Имеем коллоса на глиняных ногах.
> Какого хуя это типо быстрее?
такого, что все это в памяти. Перерисовывать всю страницу на охуенно быстром С++ все же медленнее, чем рассчитать дифф в памяти. Ну и вообще идея чистых функций и иммутабельного стейта позволяет очень хорошо все оптимизировать. Настолько, что в браузеры это скоро затащат на нативном уровне (гуглить shadow dom), и тогда будет побыстрее.
А вообще основная проблема всех этих реакт-хуяктов к том, что все эти технологии нихуя не дружат с кэшированием. Десятки лет люди придумывали, как бы нам лишнего не качать. Придумывали, как серверу кэшировать часть HTML странички и отдавать кусочками на 100мс быстрее. Но пришли JSеры и сказали "хуй клали на ваши кэши", сделали собственный рендер, навернули собственных кэшей (которые тоже на ЖС), ну и получилось что получилось. И теперь сервачок кэширует килобайт страницы, в котором написанно только и радуется, что он может переиспользовать один и тот же овтет для всех клиентов. А вот клиенты охуевают, потому что после как бы "скачанной страницы" начинают грузиться мегабайты скриптов, которые призваны ускорить работу. Такие дела.
такого, что все это в памяти. Перерисовывать всю страницу на охуенно быстром С++ все же медленнее, чем рассчитать дифф в памяти. Ну и вообще идея чистых функций и иммутабельного стейта позволяет очень хорошо все оптимизировать. Настолько, что в браузеры это скоро затащат на нативном уровне (гуглить shadow dom), и тогда будет побыстрее.
А вообще основная проблема всех этих реакт-хуяктов к том, что все эти технологии нихуя не дружат с кэшированием. Десятки лет люди придумывали, как бы нам лишнего не качать. Придумывали, как серверу кэшировать часть HTML странички и отдавать кусочками на 100мс быстрее. Но пришли JSеры и сказали "хуй клали на ваши кэши", сделали собственный рендер, навернули собственных кэшей (которые тоже на ЖС), ну и получилось что получилось. И теперь сервачок кэширует килобайт страницы, в котором написанно только и радуется, что он может переиспользовать один и тот же овтет для всех клиентов. А вот клиенты охуевают, потому что после как бы "скачанной страницы" начинают грузиться мегабайты скриптов, которые призваны ускорить работу. Такие дела.
А сами игры теперь по 50 Гб с пререндерами в 4к и "текстурами следующего поколения" с которыми игра будет тормозить как сейчас даже через 10 лет потому что "10 лет назад мы не знали технологий будущего и не могли под них оптимизировать". Вы бы хоть под современные оптимизировали... Кстати, об играх по 50 гб - помните такое?
https://ru.wikipedia.org/wiki/.kkrieger
https://ru.wikipedia.org/wiki/.kkrieger
меня в своё время удивляли кряки: в 2-5 килобайтный экзешник умудрялись втиснуть кейген с форомой и ивентами, текстуру-бекграунд окна (часто не-прямоугольной формы) и ещё и с музычкой которая не зациклена.
и, по-моему, 4-килобайтная демка mars.exe с 3d-рельефом, по которому можно было двигаться мышкой в 4-х направлениях и с небом
Я не случайно сделал акцент на пререндеренные ролики. Надо было, значит, ещё уточнить, что имелись ввиду ролики на движке. Т.е. вместо того чтоб впихнуть скрипт на пару килобайт как модельки должны двигаться и камера летать они всё это пишут в видео блу-рей качества. Да и вообще, реально ли так выросло качество тех же текстур за последние годы? Как по мне, они не ближе к фотореализму чем 5 лет назад. А скоро чтоб новые RTX покупались ещё и 3d-модели перестанут оптимизировать и пихать в игры сырой экспорт из редактора на овердохуя полигонов. А чё заморачиваться-то... Не трогай, это на некстген.
Чтобы написать коммент, необходимо залогиниться
