I>>>Ты в курсе, что программа на ассемблере, текстовый вьювер, занимает памяти на порядки меньше с++ варианта. PD>>Нет. Это совершенно неверно. Он не только на порядки, он даже и в 2 раза больше не занимает.
I>Напиши на с++ вьювер ровно в 300 байт
Я же ясно сказал — серьезные программы. Для поделок (а тем более TSR, помнишь их ?) — могут в разы, да. Но если программа на С++ занимает хоть 1 Мб, то на асме ты ее в 500 Кб не уложишь. В 800- возможно. Ну а под Windows определенное место займут системные DLL, это вообще от языка не зависит.
А для программ размером в 300 байт — ладно, 1 Кб дам. Но 2 не дам
>>Объем кода серьезной программы на С++ по сравнению с объемом кода на асме незначительно (на проценты, от силы десятки процентов) больше, а объем данных и ресурсов от языка не зависит : массив в 100 Кб займет 100 Кб, опиши его хоть на С, хоть на Паскале, хоть на асме.
I>Об чем речь — чем _серьезнее_ программа, тем больше объем кода и вобщем то расход памяти. Чем больше памяти — тем больше можно кешировать вычисления вместо вычислений.
Объем кода вообще ничтожен по сравнению с объемом данных. Написать 100 Кб кода — это ты быстро не сделаешь, это десяток тысяч строк. А массив в 100 Кб — пустяк, превратить его в 1 Мб массив, если понадобится — раз плюнуть.
Что касается кеширования вместо вычислений — да, но далеко не везде есть это кеширование и вычисления тоже. Мне как-то трудно понять, что же там можно кешировать или вычислять, скажем, в flashget
PD>>Каждому юзеру вполне хватило бы, я так думаю, 16-32 Мб за глаза. Хватало же, когда памяти на машине было именно столько. Что с тех пор радикально нового в JS появилось ?
I>Быстродействие JS увеличилось примерно на порядок. Еще раз — быстродействие JS, а не процессора.
А процессора по сравнению с 90-ми — на 2 порядка. Плюс многоядерность. Так что прежний интерпретатор (если бы он был хорошо написан) должен был бы и без всякой компиляции на нынешних Athlon/Dual/i7 летать.
I>Считаешь, что старый браузер супротив нового на том же компе будет зависеть от процессора ?
Не понял вопрос. Как можно зависеть или не зависеть от процессора на том же компе ?
PD>>А если не секрет, на что он там ее увеличивает ? Вычисления обычно не в JS, а на сервере делают.
I>Вот так откровение. Открой чуть не любой сайт — JS этого бывает по 50 и даже 100 кб самое обычно дело и это не на сервере а вбраузере выполняется.
Да бога ради, 50-100 Кб — на здоровье. Что тут особенного ? Что я, файлы на С/С++ размером в 100 Кб не видел, что ли ? И компилировал их ТурбоС на 1 Мб ОП в DOS со вполне приличной скоростью. А TурбоПаскаль так просто летал.
I>>>Может и уже джитят, не уверен. Если джитят — то памяти просто должно расходоваться очень много.
PD>>А компилятор с Фортрана в 70-е годы работал на 256 Килобайтах. А ТурбоПаскаль с ООП в 80-е годы на 1 Мбайте. Во сколько раз JS сложнее ТурбоПаскаля ?
I>И работали они тогда крайне медленно.
Ничего подобного. ТурбоПаскаль очень быстро работал. Найди его и запусти, убедишься сам. Он на Ямахе (2MHz, 64 Kb) компилировал 2000 строк за десять секунд.
I>>>DOM-модель это уже не XML, это объктна модель где объекты соответсвуют элементам xml.
PD>>Это я все знаю, поверь.
I>Не похоже.
Что не похоже-то ? Я же тебе ниже все написал.
PD>>Об XML я говорил, имея в виду его как источник данных. Вот есть у тебя, к примеру. 1 Мб XML файл. Там строки, числа и т.д. Построили из него дерево. Сколько памяти это дерево должно занимать ?
I>Зависит от функционала модели и оптимизации. Может и в 1000 раз больше быть.
А вот тут опять же поподробнее. Дерево я тебе приводил, оверхед там рассчитал чуть ли не с калькулятором. А вот если в 1000 раз больше — давай сюда свой расчет памяти.
I>Например понадобится доступ к элементам O(1) при том что коллекции у каждого элемента всегда должны быть отсортированые. Или окажется что порядок следования в коллекции не должен меняться.
Доступ за O(1) при том, что при каждом добавлении тебе придется либо пересортировывать либо сдвигать ?
Я не спорю, такое возможно. Но ИМХО тут надо как следует задачу перепродумать и структуры данных. Слишком уж разбалансированное решение получилось.
>>Я так полагаю, что примерно тот же 1 Мб, ну пусть раза в 2-4 больше (на всякие там ссылки, может, в текстовой форме меньше памяти уходило, допустим). А вот больше — под что ????
I>Это еще 10 лет назад было не так. Качни любой парсер, который DOM-умеет, да открой 100 мб xml, памяти у тебя ведь больше 1 гига ? Стало быть за глаза хватит
Это и было и есть не так, потому что писали это и пишут черт те как.
PD>>Да бога ради. Вот тебе классическое двоичное дерево. Ссылки на родителя в нем обычно не хранят — и так хорошо. Расход памяти на узел
I>У тебя возникли какие то проблемы со фразой "(просьба примеры не обсуждать, они взяты немного из другой области, не DOM)" ?
Ну знаешь, если ты пошел по пути приведения примеров и при этом запрещаешь мне их обсуждать, то лучше было бы тебе их и не приводить. А то как-то неэтично получается.
I>Тебе что, перечислить все возможные оптимизации которые я делал для ускорения модели ?
Я понятия не имею о твоей модели (и о задаче), так что мне это совсем ни к чему. Я тоже делал всякие оптимизации для ускорения, потому что от меня эту скорость именно и требовали, но все же памятью не бросался , хотя мне никто ограничений на этот счет не делал.
I>После всех оптимизаций модель больше похожа на БД в памяти. Ты представляешь, что такое БД ?
Нет. Никогда их не видел и о них не слышал. . Тебе обсудить что-то хочется или поерничать ?
I>Модель загоняю в БД на SQL Сервере, получается около 100 мб, а в текстовом виде и сто килобайт не наберется.
Вот именно, типичный пример. 0.01% данных и 99.99 % накладных расходов. Лей память, лей, чего ее жалеть!
I>В памяти конечно нет 100 мб, мне индексы не нужны, но около 20мб имеется.
Павел, давай сразу оговорюсь: я не считаю, что на затраты памяти можно плевать вообще, в принципе. Я лишь пытаюсь объяснить, почему именно в хроме эти затраты более-менее оправданы и аргументированы. Ок?
PD>А вот когда мне говорят, что для обеспечения безопасности нужно 100 Мб — это я не понимаю. Что там за данные, которых аж 100 Мб набралось ?
Не только для обеспечения безопасности. Но не в стихах же мне всю архитектуру хрома излагать?
PD>Ну а что касается процесса под вкладку — извини, но ты тут просто демонстрируешь незнание базовых механизмов.
Павел извини, но то что я не программист еще не значит, что я не в курсе, чем физическое адресное пространство отличается от виртуального, спасибо
Твоя ошибка в том, что ты считаешь, что:
PD>Понимаешь, 100 Мб — это массив данных, и очень большой массив.
а это не совсем массив данных (да и не очень большой, если честно)
Давай разберемся что это:
во-первых, 100 мегабайт (на самом деле, чуть больше, по крайней мере у меня, из-за установленных расширений) — это не на каждый процесс, это в сумме на все, если что:
это скрин одного экземпляра приложения google chrome с тремя открытыми вкладками: gmail, google reader и вкладкой диагностики памяти. Кроме того, в моем хроме установлены 5 расширений и один плагин на каждый из которых тоже создается свой процесс. Вот как это выглядит в упомянутой вкладке диагностики:
Павел, обрати внимание на понятия memory и virtual memory. Проведем простой эксперимент, откроем еще по одной вкладке почты и новостей:
Смотри, на сколько увеличилось потребление невиртуальной памяти. Т.е. как бы той readonly о которой ты говоришь и которую можно было бы замапить в другие процессы, там не так уж и много.
А хочешь я тебе еще и фокус один покажу? Следи за руками:
Почти сотни метров — как ни бывало. И только за счет запихивания всех открытых страниц в один процесс. Фишка в том, что у хрома есть три стратегии распределения контента по процессам: процесс на каждый экземпляр сайта, процесс на каждый сайт и процесс на каждый таб. По умолчанию используется первый (а в свежих версиях они кажется начали экспериментировать с динамическим переключением между стратегиями), но это легко исправляется ключами командной строки.
Т.о., как видишь, мультипроцессная модель управления памятью дает весьма приличный оверхед. Каждый процесс хрома (кроме одного — супервизора) оборачивается в песочницу, изолирующую его от остальных процессов куда более гибче, чем это делает та же винда (с линуксом, там все несколько иначе). Все механизмы межпроцессного взаимодействия для этих песочниц реализованы руками и их необходимо дублировать от процесса к процессу, чтобы повреждение памяти в одном (к примеру) не сказалось на всех остальных. Та же фигня и со всеми структурами данных, используемых песочницами и собственно самих данных. Шарить это нельзя, т.к. это сведет на нет все усилия по изоляции процессов друг от друга.
Но ведь это еще не все Javascript в хроме исполняется движком V8 одной из отличительных черт которого является способ представления объектов в памяти процесса. Вместо того, чтобы держать хэш таблицы для доступа ко всем динамическим членам объектов, V8 при каждом изменении какого-либо объекта (например, при добавлении в него нового поля) создает на базе этого объекта т.н. скрытый класс, унаследованный от текущей структуры объекта, который в дальнейшем используется в качестве прототипа при создании новых объектов и для доступа к его членам. Это позволяет избежать поиска динамических членов по всей цепочке иерархии и существенно ускорить доступ к членам (т.к. эти скрытые классы еще и джитятся в нативный код), за счет опять-таки, затрат памяти, т.к. всю эту иерархию нужно хранить на протяженнии всего жизненного цикла скрипта (ибо таков суровый мир динамических языков). Мне лень делать скриншоты (кому надо — проверят сами), но разница между открытым gmail в режиме html-only и его представлением по умолчанию измеряется не одним десятков мегабайт, именно за счет того, что броузеру не приходится плодить все эти скрытые классы:
невиртуальная память (приватная, шарящаяся, всего):
html gmail: 12376k 11812k 24188k
ajax gmail: 68676k 12796k 81472k
А, ну да, вот Ikemefula про DOM сказал, а я забыл. Там тоже имеют место оптимизации для ускорения времени доступа к его узлам из скриптов и тоже за счет затрат памяти, как это ни странно.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Напиши на с++ вьювер ровно в 300 байт
PD>Я же ясно сказал — серьезные программы. Для поделок (а тем более TSR, помнишь их ?) — могут в
С одной стороны, ты понимаешь, что программы различаются по серьезности.
С другой сторны, как только доходит до расхода памяти, ты вдруг отказываешься это понимать.
Как быть и не знаю.
PD>Объем кода вообще ничтожен по сравнению с объемом данных. Написать 100 Кб кода — это ты быстро не сделаешь, это десяток тысяч строк. А массив в 100 Кб — пустяк, превратить его в 1 Мб массив, если понадобится — раз плюнуть.
А если генерировать код, что тогда ?
PD>Что касается кеширования вместо вычислений — да, но далеко не везде есть это кеширование и вычисления тоже. Мне как-то трудно понять, что же там можно кешировать или вычислять, скажем, в flashget
Неправильно думаешь. Тебя должен интересовать один вопрос — какое направление оптимизации выбрали для написания флешгета.
Вот когда ты это установишь наверняка и ознакомишься с кодом, тогда можно говорить, что де флешкгет расходует память зазря.
I>>Быстродействие JS увеличилось примерно на порядок. Еще раз — быстродействие JS, а не процессора.
PD>А процессора по сравнению с 90-ми — на 2 порядка. Плюс многоядерность. Так что прежний интерпретатор (если бы он был хорошо написан) должен был бы и без всякой компиляции на нынешних Athlon/Dual/i7 летать.
Будет летать, а программы на нем будут ползать по сравнению с современными JS-машинами на "нынешних Athlon/Dual/i7"
I>>Считаешь, что старый браузер супротив нового на том же компе будет зависеть от процессора ?
PD>Не понял вопрос. Как можно зависеть или не зависеть от процессора на том же компе ?
Все ты понял. Нечего валять Ваньку.
Если сравнение JS vs JS, то очевидно, остальные параметры эквивалентны или их влиянием можно пренебречь.
Но тебе толи хочется повыступать, то ли увильнуть, и ты вводишь спам про процессоры.
PD>Да бога ради, 50-100 Кб — на здоровье. Что тут особенного ?
Особенного здесь тот факт, что JS-кода сейчас на порядки больше чем 10 лет назад, и работает он много быстрее относительно одного и того же процессора.
I>>И работали они тогда крайне медленно.
PD>Ничего подобного. ТурбоПаскаль очень быстро работал. Найди его и запусти, убедишься сам. Он на Ямахе (2MHz, 64 Kb) компилировал 2000 строк за десять секунд.
Это и есть крайне медленно. Во первых, язык был убог. Во вторых, оптимизаций считай никаких не делалось.
I>>Зависит от функционала модели и оптимизации. Может и в 1000 раз больше быть.
PD>А вот тут опять же поподробнее. А вот если в 1000 раз больше — давай сюда свой расчет памяти.
Ага, щаз, перечислить тебе все виды оптимизации которыее вводились за несколько лет ?
Ты в своем уме ? Каждая из этих оптимизаций прибавляет по n-байт в рассчете на объект или коллекцию.
По одной — ничего, все вместе — может и в 1000 раз.
I>>Например понадобится доступ к элементам O(1) при том что коллекции у каждого элемента всегда должны быть отсортированые. Или окажется что порядок следования в коллекции не должен меняться.
PD>Доступ за O(1) при том, что при каждом добавлении тебе придется либо пересортировывать либо сдвигать ?
Имеется ввиду доступ на чтение. Хештаблица — медленное решение. Предложи лучше.
PD>Я не спорю, такое возможно. Но ИМХО тут надо как следует задачу перепродумать и структуры данных. Слишком уж разбалансированное решение получилось.
Балансировалось только под оптимизацию по быстройдействию.
Все остальное тупо шло в помойку.
PD>Это и было и есть не так, потому что писали это и пишут черт те как.
Это тянет на д'Артаньяна в стране Каналий
I>>У тебя возникли какие то проблемы со фразой "(просьба примеры не обсуждать, они взяты немного из другой области, не DOM)" ?
PD>Ну знаешь, если ты пошел по пути приведения примеров и при этом запрещаешь мне их обсуждать, то лучше было бы тебе их и не приводить. А то как-то неэтично получается.
Нормально получается. Я знаю, сколько какая из оптимизаций прибавляет к расходу памяти и эти самый оптимизации могу перечислять десятками точно.
Ты кажду будешь мусолить ?
PD>Я понятия не имею о твоей модели (и о задаче), так что мне это совсем ни к чему.
Вот я тебе и говорю — не надо обсуждать примеры.
I>>После всех оптимизаций модель больше похожа на БД в памяти. Ты представляешь, что такое БД ?
PD>Нет. Никогда их не видел и о них не слышал. . Тебе обсудить что-то хочется или поерничать ?
О том и речь, что ты говришь о том, чего не знаешь.
I>>Модель загоняю в БД на SQL Сервере, получается около 100 мб, а в текстовом виде и сто килобайт не наберется.
PD>Вот именно, типичный пример. 0.01% данных и 99.99 % накладных расходов. Лей память, лей, чего ее жалеть!
Да, именно так. Потому что имеет смысл тольк одна оптимизация — под быстродействие.
I>>В памяти конечно нет 100 мб, мне индексы не нужны, но около 20мб имеется.
PD>0.05% и 99.95%
Да, примерно так. И меня абсолютно не удивляет, почему Хром жрет память.
Это десктоп приложение, посмотри на тренд — доля Хрома растет со страшной скоростью.
Это самый быстрый браузер из аналогичных по функционалу и скорость окупается.
Оптимизация под память затребует дополнительных усилий и времени. За счет чего — выбирать не из чего, или функционал или перформанс.
А память стоит дешево, кстати говоря. Боязнь расхода памяти это психологический барьер после 20 лет 32х приложений.
Здравствуйте, kochetkov.vladimir, Вы писали:
PD>>Ну а что касается процесса под вкладку — извини, но ты тут просто демонстрируешь незнание базовых механизмов.
KV>Павел извини, но то что я не программист еще не значит, что я не в курсе, чем физическое адресное пространство отличается от виртуального, спасибо
Речь шла не об этом отличии.
KV>Твоя ошибка в том, что ты считаешь, что:
PD>>Понимаешь, 100 Мб — это массив данных, и очень большой массив.
KV>а это не совсем массив данных (да и не очень большой, если честно)
Все есть массив данных
KV>Давай разберемся что это:
KV>Павел, обрати внимание на понятия memory и virtual memory.
Вот отсюда я и остановлюсь. Дело в том, что никакого понятия memory в противовес virtual memory в Windows не существует. Что это такое — знает только хром, это его понятие, мне оно неизвестно, поэтому оценить твои последующие рассуждения не могу.
(Если же речь идет о рабочем множестве (working set) — это вообще не показатель, так как может изменяться в очень широких пределах без какого либо участия процесса — просто потому, что Windows решила расширить РМ или , наоборот, отнять страницы).
KV>Смотри, на сколько увеличилось потребление невиртуальной памяти.
Не могу я спокойно на это смотреть — не на картинку, а на твои слова. Нет никакой невиртуальной памяти вообще у процесса, хоть он хром, хоть марганец
>Т.е. как бы той readonly о которой ты говоришь и которую можно было бы замапить в другие процессы, там не так уж и много.
Readonly память тоже виртуальная. Опять ты запутался. Ее не надо мапить в другие процессы — она сама мапится. Более того, это просто нельзя отменить. Хоть он хром, хоть черт лысый, а те страницы, которые readonly, все равно будут в ФП в одном экземпляре. И эти страницы там будут обязательно.
KV>Т.о., как видишь, мультипроцессная модель управления памятью дает весьма приличный оверхед. Каждый процесс хрома (кроме одного — супервизора) оборачивается в песочницу, изолирующую его от остальных процессов куда более гибче, чем это делает та же винда
Для того, чтобы любой процесс изолировать от остальных процессов, не надо никакой песочницы. Он и так изолирован. Наоборот, надо предпринять меры, чтобы иметь общую память. Тот факт, что readonly страницы присутствуют в ФП один раз, в этом плане ничего, абсолютно ничего не меняет. Никакой возможности изменить страницу в чужом процессе нет, пока не предприняты специальные действия. Если их не предпринимать, то нет , и все!
>Все механизмы межпроцессного взаимодействия для этих песочниц реализованы руками
Все механизмы межпроцессного взаимодействия всегда реализуются руками.
>и их необходимо дублировать от процесса к процессу, чтобы повреждение памяти в одном (к примеру) не сказалось на всех остальных.
Повреждение памяти в каком бы то ни было процессе никогда не может сказаться на всех других процессах, если не используется не-readonly общая память.
>Та же фигня и со всеми структурами данных, используемых песочницами и собственно самих данных. Шарить это нельзя, т.к. это сведет на нет все усилия по изоляции процессов друг от друга.
Ты, увы, опять не понимаешь сути. Шарить не то что нельзя или можно — шарить общие данные R/O будет Windows независимо от твоего желания. Просто иначе не бывает. Что же касается R/W данных — их и не надо шарить, и без всякой песочницы их никто не шарит.
Вот смотри
char* p = "Sample";
В процессе A текст "Sample" хранится в R/O памяти,в некоей странице. Это страница ВП, ей соответствует страница ФП. Эта же страница ФП выделена процессу B, и это нельзя отменить!
Если же процесс B попробует изменить общие данные, то возможны 2 варианта. В случае выше просто будет access violation. В других случаях это разрешается, но срабатывает механизм write copy. При этом делается копия страницы и процессу подсовывается эта копия вместо оригинала. Остальные процессы продолжают пользоваться оригиналом. Так что и в этом случае никакого изменения страниц чужого процесса быть не может.
KV>Но ведь это еще не все Javascript в хроме исполняется движком V8 одной из отличительных черт которого является способ представления объектов в памяти процесса. Вместо того, чтобы держать хэш таблицы для доступа ко всем динамическим членам объектов, V8 при каждом изменении какого-либо объекта (например, при добавлении в него нового поля) создает на базе этого объекта т.н. скрытый класс, унаследованный от текущей структуры объекта, который в дальнейшем используется в качестве прототипа при создании новых объектов и для доступа к его членам. Это позволяет избежать поиска динамических членов по всей цепочке иерархии и существенно ускорить доступ к членам (т.к. эти скрытые классы еще и джитятся в нативный код), за счет опять-таки, затрат памяти, т.к. всю эту иерархию нужно хранить на протяженнии всего жизненного цикла скрипта (ибо таков суровый мир динамических языков). Мне лень делать скриншоты (кому надо — проверят сами), но разница между открытым gmail в режиме html-only и его представлением по умолчанию измеряется не одним десятков мегабайт, именно за счет того, что броузеру не приходится плодить все эти скрытые классы:
Вот именно. Вместо того, чтобы оптимизировать код и найти оптимальные алгоритмы, пошли по пути захвата лишней памяти. Сколько там этих объектов (переменных), в обычном файле на js ? Сотни ? Тысячи ? Ну пусть даже десятки тысяч! И на это нужны десятки Мб ? По Кбайту оверхеда на текстовую строку ?
PD>>Я же ясно сказал — серьезные программы. Для поделок (а тем более TSR, помнишь их ?) — могут в
I>С одной стороны, ты понимаешь, что программы различаются по серьезности.
I>С другой сторны, как только доходит до расхода памяти, ты вдруг отказываешься это понимать.
I>Как быть и не знаю.
PD>>Объем кода вообще ничтожен по сравнению с объемом данных. Написать 100 Кб кода — это ты быстро не сделаешь, это десяток тысяч строк. А массив в 100 Кб — пустяк, превратить его в 1 Мб массив, если понадобится — раз плюнуть.
I>А если генерировать код, что тогда ?
Тогда, извини, это не код. Это данные, которые обрабатываются специальным образом. Текст на JS — это не код, а данные для интерпретатора (или как он там) JS.
PD>>Что касается кеширования вместо вычислений — да, но далеко не везде есть это кеширование и вычисления тоже. Мне как-то трудно понять, что же там можно кешировать или вычислять, скажем, в flashget
I>Неправильно думаешь. Тебя должен интересовать один вопрос — какое направление оптимизации выбрали для написания флешгета.
Правильно думаю . Нечего там во flashget кешировать — 2 раза я один и тот же файл не качаю, а если и качаю, то все равно нельзя кешировать и незачем.
I>Вот когда ты это установишь наверняка и ознакомишься с кодом, тогда можно говорить, что де флешкгет расходует память зазря.
А он ее не расходует.
I>>>Быстродействие JS увеличилось примерно на порядок. Еще раз — быстродействие JS, а не процессора.
PD>>А процессора по сравнению с 90-ми — на 2 порядка. Плюс многоядерность. Так что прежний интерпретатор (если бы он был хорошо написан) должен был бы и без всякой компиляции на нынешних Athlon/Dual/i7 летать.
I>Будет летать, а программы на нем будут ползать по сравнению с современными JS-машинами на "нынешних Athlon/Dual/i7"
Каких еще программ ? Если имеем дело с чистым интерпретатором, то его работа и есть исполнение программы
I>>>Считаешь, что старый браузер супротив нового на том же компе будет зависеть от процессора ?
PD>>Не понял вопрос. Как можно зависеть или не зависеть от процессора на том же компе ?
I>Все ты понял. Нечего валять Ваньку.
Глупо. Я действительно не понял.
I>Если сравнение JS vs JS, то очевидно, остальные параметры эквивалентны или их влиянием можно пренебречь.
I>Но тебе толи хочется повыступать, то ли увильнуть, и ты вводишь спам про процессоры.
Да какой к черту спам! Я тебе ясно объяснил свою мысль — о том, что скорость процессора резко возросла, а поэтому старый интерпретатор должен работать в N раз быстрее, чем в 90-е годы. Вот и все.
PD>>Да бога ради, 50-100 Кб — на здоровье. Что тут особенного ?
I>Особенного здесь тот факт, что JS-кода сейчас на порядки больше чем 10 лет назад, и работает он много быстрее относительно одного и того же процессора.
Что значит его больше ? На HTML-странице ? На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ? Ты вообще много файлов .html видел размером в 500 Кбайт ?
Поосторожнее с порядками!
I>>>И работали они тогда крайне медленно.
PD>>Ничего подобного. ТурбоПаскаль очень быстро работал. Найди его и запусти, убедишься сам. Он на Ямахе (2MHz, 64 Kb) компилировал 2000 строк за десять секунд.
I>Это и есть крайне медленно. Во первых, язык был убог. Во вторых, оптимизаций считай никаких не делалось.
Язык Turbo Pascal с классами (object) был более убог, чем JS ? Не смеши!
PD>>А вот тут опять же поподробнее. А вот если в 1000 раз больше — давай сюда свой расчет памяти.
I>Ага, щаз, перечислить тебе все виды оптимизации которыее вводились за несколько лет ?
Имеешь полное право не перечислять. Но и я имею полное право при этом твоим утверждениям не поверить.
I>Ты в своем уме ? Каждая из этих оптимизаций прибавляет по n-байт в рассчете на объект или коллекцию.
I>По одной — ничего, все вместе — может и в 1000 раз.
И сколько нужно оптимизаций, чтобы увеличивая на n, получить увеличение в 1000 раз ? Пусть изначально было 100 байт. На первой оптимизации добавили, допустим, еще 100. Итого в 2 раза. На второй еще 100. Теперь в 3 раза. Сдается мне, что надо 1000 оптимизаций, а поскольку не всякая оптимизация прибавляет байты (скажем, замена пузырька на quicksort их вообще не добавляет), то и все 2000. После этих 2000 оптимизаций вся программистская конница и вся программисткая рать в этом коде разобраться не сможет
I>>>Например понадобится доступ к элементам O(1) при том что коллекции у каждого элемента всегда должны быть отсортированые. Или окажется что порядок следования в коллекции не должен меняться.
PD>>Доступ за O(1) при том, что при каждом добавлении тебе придется либо пересортировывать либо сдвигать ?
I>Имеется ввиду доступ на чтение. Хештаблица — медленное решение. Предложи лучше.
Совокупность массивов указателей на общие данные.
I>Балансировалось только под оптимизацию по быстройдействию.
Я понимаю. То есть тебе поставили условие — выжать максимум скорости без ограничений по памяти. Знакомо.
PD>>Это и было и есть не так, потому что писали это и пишут черт те как.
I>Это тянет на д'Артаньяна в стране Каналий
У меня что-то сегодня ассоциации плохо работают
PD>>Ну знаешь, если ты пошел по пути приведения примеров и при этом запрещаешь мне их обсуждать, то лучше было бы тебе их и не приводить. А то как-то неэтично получается.
I>Нормально получается. Я знаю, сколько какая из оптимизаций прибавляет к расходу памяти и эти самый оптимизации могу перечислять десятками точно.
I>Ты кажду будешь мусолить ?
Нет, не буду. Но имея десятки оптмизаций и прибавляя на каждой n байт, очень сложно увеличить расход памяти в 1000 раз
PD>>Я понятия не имею о твоей модели (и о задаче), так что мне это совсем ни к чему.
I>Вот я тебе и говорю — не надо обсуждать примеры.
I>>>После всех оптимизаций модель больше похожа на БД в памяти. Ты представляешь, что такое БД ?
PD>>Нет. Никогда их не видел и о них не слышал. . Тебе обсудить что-то хочется или поерничать ?
I>О том и речь, что ты говришь о том, чего не знаешь.
Слушай, ты вообще серьезный человек или нет ? Ну что ты ерунду-то говоришь! Что я не знаю ? Или ты впрямь решил, что я никогла БД не видел ?
I>>>Модель загоняю в БД на SQL Сервере, получается около 100 мб, а в текстовом виде и сто килобайт не наберется.
PD>>Вот именно, типичный пример. 0.01% данных и 99.99 % накладных расходов. Лей память, лей, чего ее жалеть!
I>Да, именно так. Потому что имеет смысл тольк одна оптимизация — под быстродействие.
Оптимизацию под быстродействие совсем не всегда необходимо сочетать с дополнительным расходом памяти. Можно изменить алгоритм, лучшим способом разместить данные и т.д. Кстати, увеличивая расход памяти, уменьшаешь и быстродействие иногда — на обработку этой дополнительной памяти нужно время.
I>>>В памяти конечно нет 100 мб, мне индексы не нужны, но около 20мб имеется.
PD>>0.05% и 99.95%
I>Да, примерно так. И меня абсолютно не удивляет, почему Хром жрет память.
Дв и меня не удивляет. Только вот причины этого неудивления у нас с тобой различны
I>Это десктоп приложение, посмотри на тренд — доля Хрома растет со страшной скоростью.
I>Это самый быстрый браузер из аналогичных по функционалу и скорость окупается.
I>Оптимизация под память затребует дополнительных усилий и времени. За счет чего — выбирать не из чего, или функционал или перформанс.
I>>Особенного здесь тот факт, что JS-кода сейчас на порядки больше чем 10 лет назад, и работает он много быстрее относительно одного и того же процессора.
PD>Что значит его больше ? На HTML-странице ? На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ? Ты вообще много файлов .html видел размером в 500 Кбайт ? PD>Поосторожнее с порядками!
при чем тут HTML страница? Открою страшную тайну: js- код может подгружаться из внешних файлов
inbox GMail'а загружает аяксом — внимание — 2.8 MB данных:
И загружается там не банальный JSON, а
На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
Банальный RSDN подгружает 50 килобайтов скриптов.
google.com подгружает 188 килобайтов скриптов и 22 килобайта скрипттов аякс-запросом. первый же поиск по слову test увеличивает XHR до 361 килобайта.
M>при чем тут HTML страница? Открою страшную тайну: js- код может подгружаться из внешних файлов
А я и не знал .
M>inbox GMail'а загружает аяксом — внимание — 2.8 MB данных: M>
Да уж. Gmail это умеет
M>И загружается там не банальный JSON, а
M>
M>На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
Я все же одно не пойму. ТурбоПаскаль 1987 года тихо и спокойно переварил бы файл на 177.27 Кб при 640 Кб ОП и не почесался бы. Подумаешь, 177 Кб. Ну ладно, на тебе в 10 раз больше. А в 100 зачем ? Что за чудная такая задача — интерпретатор с несложного, в общем-то, языка, к тому же большая часть кода в котором есть вызовы браузера (всякие document.open и window.on_не_знаю_что)
M>Банальный RSDN подгружает 50 килобайтов скриптов. M>google.com подгружает 188 килобайтов скриптов и 22 килобайта скрипттов аякс-запросом. первый же поиск по слову test увеличивает XHR до 361 килобайта.
И что ? 50, 188, 22, а не 500 и 5000
M>Так что с порядками все в порядке.
M>>при чем тут HTML страница? Открою страшную тайну: js- код может подгружаться из внешних файлов PD>А я и не знал .
Тогда почему ты заострил внимание на «одной HTML-странице в 500 килобайт»?
M>>inbox GMail'а загружает аяксом — внимание — 2.8 MB данных: M>>http://files.rsdn.ru/9088/gmail%20ajax.png
PD>Да уж. Gmail это умеет
Улыбки улыбками, но там грузится не 50 килобайтов скриптов, а почти 3 мегабайта.
M>>На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
PD>Я все же одно не пойму. ТурбоПаскаль 1987 года тихо и спокойно переварил бы файл на 177.27 Кб при 640 Кб ОП и не почесался бы. Подумаешь, 177 Кб. Ну ладно, на тебе в 10 раз больше. А в 100 зачем ? Что за чудная такая задача — интерпретатор с несложного, в общем-то, языка, к тому же большая часть кода в котором есть вызовы браузера (всякие document.open и window.on_не_знаю_что)
Javascript кажется несложным. Тут тебе и динамика и функции высшего порядка и замыкания и eval. Но его обработка ускоряется. Повторю, что интерпретатор 10-летней давности умер бы на 2 мегабайтах скриптов.
На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ?
10 лет тому назад 5 килобайт.
RSDN: 50 килобайт. Разница на порядок.
google.com: 188-361 килобайт. Разница на два порядка.
gmail.com: 2800 килобайт. Разница на три порядка.
Все в порядке с порядками. Более того, если 10 лет тому назад две-три страницы с большими/активными яваксриптами могли намертво и надолго завесить браузер, то сейчас не проблема иметь в одном окне gmail, в другом — твиттер, в третьем — facebook и т.д. и т.п., а в нцатом спокойно что-нибудь искать в google instant (да еще и с предосмотром страниц).
Здравствуйте, v2kochetov, Вы писали:
V>Здравствуйте, frogkiller, Вы писали:
F>>Здравствуйте, Ikemefula, Вы писали:
I>>>Очнись, ICQ это уже давно не мессенгер. И там есть и гипертекст, и стили и много чего еще.
F>>Ну и нахрена это всё там, спрашивается V>Для удобства, разве нет? Форматирование текста придумали давно, значит оно нужно, а значит полезно и удобно в Instant Messenger. А там делать форматированый текст наиболее естественно используя гипертекст. Стили просто добавляют комфорта — кому-то удобнее читать белым по черному, кому-то черным по белому, а дебилам голубым по розовому — все довольны.
ни разу не отправлял и не принимал форматированных мессаг.
ты точно уверен, что это — не маркетинговая плюшка?
Здравствуйте, Mamut, Вы писали:
M> Javascript кажется несложным. Тут тебе и динамика и функции высшего порядка и замыкания и eval. Но его обработка ускоряется. Повторю, что интерпретатор 10-летней давности умер бы на 2 мегабайтах скриптов.
Что ты имеешь ввиду, когда говоришь "умер"? В момент трансляции или в момент исполнения? Я тебе могу показать семилетней давности интерпретатор, правда не JavaScript, который 4Мб скрипт (синтетический правда) транслирует за 2 сек, а интерпретирует (исполняет т.е.) за 60 мсек (без джитов и прочего).
M>> Javascript кажется несложным. Тут тебе и динамика и функции высшего порядка и замыкания и eval. Но его обработка ускоряется. Повторю, что интерпретатор 10-летней давности умер бы на 2 мегабайтах скриптов.
H>Что ты имеешь ввиду, когда говоришь "умер"? В момент трансляции или в момент исполнения? Я тебе могу показать семилетней давности интерпретатор, правда не JavaScript, который 4Мб скрипт (синтетический правда) транслирует за 2 сек, а интерпретирует (исполняет т.е.) за 60 мсек (без джитов и прочего).
Еще скажи, что этот интерпретатор использовался в IE5.5/IE6, например (как раз семь лет тому назад).
Здравствуйте, Mamut, Вы писали:
M> H>Что ты имеешь ввиду, когда говоришь "умер"? В момент трансляции или в момент исполнения? Я тебе могу показать семилетней давности интерпретатор, правда не JavaScript, который 4Мб скрипт (синтетический правда) транслирует за 2 сек, а интерпретирует (исполняет т.е.) за 60 мсек (без джитов и прочего).
M> Еще скажи, что этот интерпретатор использовался в IE5.5/IE6, например (как раз семь лет тому назад).
Причем тут IE вообще? Речь о интерпретаторах и их качествах Ты говоришь, что с течением времени они стали круче, и оправдываешь этим возросший расход памяти (а что еще ты хотел сказать говоря об умирающем на 2Mb скрипте интерпретаторе). Я тебе говорю, что и семь лет назад можно было не умирать на больших скриптах, если писать интерпретатор нормально.
Здравствуйте, Mamut, Вы писали:
M>>>при чем тут HTML страница? Открою страшную тайну: js- код может подгружаться из внешних файлов PD>>А я и не знал .
M>Тогда почему ты заострил внимание на «одной HTML-странице в 500 килобайт»?
Потому что, как правило, страницы HTML вместе с внедренным в него или иначе вставленным JS имеют размер, намного меньше. О том, что размер вырос на порядки, говорить все же не приходится. Вырос, не спорю, в несколько раз, но не на порядки.
M>>>inbox GMail'а загружает аяксом — внимание — 2.8 MB данных: M>>>http://files.rsdn.ru/9088/gmail%20ajax.png
PD>>Да уж. Gmail это умеет
M>Да и не только GMail.
Между прочим. Компиляция обычных статических языков, как я уже не раз тут замечал, вполне может идти на нескольких Мб. Доказательство простое — она шла, и с весьма приличной скоростью при памяти в Мбайты и частоте в десятки-сотню MHz и без многоядерности. Это сейчас просто начали памятью бросаться. А Язык С++ от времен BC 5.0 до нашего времени не менялся практически. А тут, видите ли, чтобы откомпилировать 2.8 Мб сорсов, нужна сотня Мб. При том, что язык довольно простой. Что же это такое, кроме как халтурное программирование ?
M>>>И загружается там не банальный JSON, а
M>>>http://files.rsdn.ru/9088/gmail%20ajax%202.png PD>>
M>Улыбки улыбками, но там грузится не 50 килобайтов скриптов, а почти 3 мегабайта.
Да пусть и 3! Вот возьми BC 3.1 в MS-DOS , процессор Пентиум-100, ОП чтобы было 4 Мб, а лучше 8 и откомпилируй эти 3 Мб. Со свистом. При том, что там еще и .h файлы включаются и компилируются, если отключены predcompiled headers. Ты будешь утверждать, что JS сложнее C++ ?
M>>>На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
PD>>Я все же одно не пойму. ТурбоПаскаль 1987 года тихо и спокойно переварил бы файл на 177.27 Кб при 640 Кб ОП и не почесался бы. Подумаешь, 177 Кб. Ну ладно, на тебе в 10 раз больше. А в 100 зачем ? Что за чудная такая задача — интерпретатор с несложного, в общем-то, языка, к тому же большая часть кода в котором есть вызовы браузера (всякие document.open и window.on_не_знаю_что)
M>Javascript кажется несложным. Тут тебе и динамика и функции высшего порядка и замыкания и eval.
Ай-яй-яй. На замыкания с eval нужно 100 Мб. А динамика — так она вроде как в любом интерпретаторе потенциально возможна, на то он и интерпретатор. К примеру, в той же FoxPro на 1 Мб в DOS-времена были переменные, тип которых изменялся во время выполнения. Что тут такого-то ?
>Но его обработка ускоряется. Повторю, что интерпретатор 10-летней давности умер бы на 2 мегабайтах скриптов.
Значит, так хорошо умели (умеют) писать эти интерпретаторы
M>>>Так что с порядками все в порядке.
PD>>Не совсем
M>Угу. Порядок — это степень 10.
Именно. На порядок — в 10 раз. На 3 порядка — в 1000. Если было 50 Кб — давай сюда HTML с JS на 50 Мб, вот это и будет 3 порядка. Только имей в виду, что у меня канал номинально 10 Мбит, так что загрузится твой JS хорошо если через минуту
M>Возьмем сначала: M>
M> На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ?
M>10 лет тому назад 5 килобайт.
А сейчас так-таки сплошь и рядом 5 Мб ? Между прочим, на его загрузку нужно 5 сек у меня, а если скорость 1-2 Мбит ?
M>RSDN: 50 килобайт. Разница на порядок. M>google.com: 188-361 килобайт. Разница на два порядка.
На 2 порядка будет все же 500, а не 188.
M>gmail.com: 2800 килобайт. Разница на три порядка.
И здесь все же надо 5000. Ты с порядками поаккуратнее
M>
M>Все в порядке с порядками. Более того, если 10 лет тому назад две-три страницы с большими/активными яваксриптами могли намертво и надолго завесить браузер, то сейчас не проблема иметь в одном окне gmail, в другом — твиттер, в третьем — facebook и т.д. и т.п., а в нцатом спокойно что-нибудь искать в google instant (да еще и с предосмотром страниц).
Счастье-то какое! Помню, в 2000-м был у меня Пентиум-3, памяти 256 Мб, тактовая 667 MHz. И работал в ней Netscape Navigator 4.7. В одном окне была почта, в другом web, а еще был composer и не помню что еще. И ничего они не вешали. Вот поиска в гугле не было, потому что не было гугла. Но поиск на altavista (я тогда ей пользовался) или rambler — без проблем.
А всего-то 256 Мб... Получается, что для того, чтобы от 5 Кб JS перейти к 500 Кб, надо объем ОП увеличить в 16 раз, тактовую в 5, ядер в 4 ! Да это просто чудовище какое-то, ваш JS .
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>А если генерировать код, что тогда ?
PD>Тогда, извини, это не код. Это данные, которые обрабатываются специальным образом. Текст на JS — это не код, а данные для интерпретатора (или как он там) JS.
То есть памяти это не жрёт ?
I>>Неправильно думаешь. Тебя должен интересовать один вопрос — какое направление оптимизации выбрали для написания флешгета.
PD>Правильно думаю . Нечего там во flashget кешировать — 2 раза я один и тот же файл не качаю, а если и качаю, то все равно нельзя кешировать и незачем.
Ты не ответил на главный вопрос — "какое направление оптимизации выбрали для написания флешгета".
Ты даже список фич не глянул, но решил что речь будто идет про кеширование
I>>Вот когда ты это установишь наверняка и ознакомишься с кодом, тогда можно говорить, что де флешкгет расходует память зазря.
PD>А он ее не расходует.
Ага, прям 0 байт занимает в памяти.
I>>Будет летать, а программы на нем будут ползать по сравнению с современными JS-машинами на "нынешних Athlon/Dual/i7"
PD>Каких еще программ ? Если имеем дело с чистым интерпретатором, то его работа и есть исполнение программы
Вот те программы, про которые ты говори " то его работа и есть исполнение программы " и будут тормозить по сравнению современными JS-машинами.
PD>Да какой к черту спам! Я тебе ясно объяснил свою мысль — о том, что скорость процессора резко возросла, а поэтому старый интерпретатор должен работать в N раз быстрее, чем в 90-е годы. Вот и все.
Ты хорошо понимаешь, как сравниваются вещи ?
Но компе ставится два браузера — старый и новый. Всё. А твой текст про процессор это спам.
Новый браузер рвёт старый в пух и прах по перформансу того же JS.
Еще раз — процессор в обоих случаях один и тот же.
I>>Особенного здесь тот факт, что JS-кода сейчас на порядки больше чем 10 лет назад, и работает он много быстрее относительно одного и того же процессора.
PD>Что значит его больше ? На HTML-странице ?
Имеется ввиду тот который необходим для показа страницы на клиентской стороне
>На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ? Ты вообще много файлов .html видел размером в 500 Кбайт ?
Очнись и пой. 10 лет назад JS считай и не было вовсе, 5 кб — это слишком большая цифра. Сумасшедший рост начался где то с 2005го.
Качни пару страниц на серьезных сайтах, где динамика всякая, ajax, jquery, и посмотри что тебе скачается на локаль.
Щас только JS может быть на десятки и даже сотни килобайт. Добавь сюда css и окажется, что html уже давно не самая большая часть страницы.
I>>Это и есть крайне медленно. Во первых, язык был убог. Во вторых, оптимизаций считай никаких не делалось.
PD>Язык Turbo Pascal с классами (object) был более убог, чем JS ? Не смеши!
Конечно убог. Сравить с турбопаскалем сложно, но можешь посмотреть сравнение с дельфи
I>>Ага, щаз, перечислить тебе все виды оптимизации которыее вводились за несколько лет ?
PD>Имеешь полное право не перечислять. Но и я имею полное право при этом твоим утверждениям не поверить.
Проще и быстрее написать книгу и издать.
I>>Ты в своем уме ? Каждая из этих оптимизаций прибавляет по n-байт в рассчете на объект или коллекцию.
I>>По одной — ничего, все вместе — может и в 1000 раз.
PD>И сколько нужно оптимизаций, чтобы увеличивая на n, получить увеличение в 1000 раз ?
Очевидно — в среднем 1000/n, и 1000 это частный случай
>Пусть изначально было 100 байт.
Откуда ты взял 100 байт ?
>На первой оптимизации добавили, допустим, еще 100. Итого в 2 раза. На второй еще 100. Теперь в 3 раза.
Бред какой то. Вот, на вскидку
Допустим у тега есть n атрибутов и вложеные теги.
1 на lpvtbl
n филдов
массив вложеных тегов
это минимально необходимое количество.
теперь
добавить филд на парента
добавить филд на рут
для быстрого доступа по имени атрибута тебе надо ввести таблицу атрибутов
для быстрого добавления тега надо вместо массива сделать коллекцию
для быстрого поиска тега по ID надо усилить коллекцию
для быстрого поиска тега по типу надо усилить коллекцию
для быстрого поиска тега по классу надо усилить коллекцию
для быстрого вызова метода по имени нужна таблица методов
для быстрого добавления метода в рантайме надо таблицу усилить
строки должны быть максимально быстрые — strlen не катит, опять расход памяти
наиболее часто вызываемые функции кешируем — снова расход памяти — таблица на каждую функцию !
А теперь фокус — для ускорения доступа к любому филду, элементу и тд вводим выравнивание, например по кешу или еще как нибудь
Теперь оказывается, что фрагментация памяти слишком большая — выделяем память большими кусками что бы хватило на основные сценарии
Теперь посчитай, как увеличится расход памяти.
При этом до html мы еще и не добрались.
Такая фича как CSS тоже ест память.
Рендеринг как ты в курсе тоже жрет память и это еще мягко сказано.
I>>>>Например понадобится доступ к элементам O(1) при том что коллекции у каждого элемента всегда должны быть отсортированые. Или окажется что порядок следования в коллекции не должен меняться.
PD>>>Доступ за O(1) при том, что при каждом добавлении тебе придется либо пересортировывать либо сдвигать ?
I>>Имеется ввиду доступ на чтение. Хештаблица — медленное решение. Предложи лучше.
PD>Совокупность массивов указателей на общие данные.
А это память не потребляет, правильно ?
I>>Ты кажду будешь мусолить ?
PD>Нет, не буду. Но имея десятки оптмизаций и прибавляя на каждой n байт, очень сложно увеличить расход памяти в 1000 раз
Это сложно понять но это так. Техника вроде memoize например потребляет просто страшное количество памяти.
PD>Слушай, ты вообще серьезный человек или нет ? Ну что ты ерунду-то говоришь! Что я не знаю ? Или ты впрямь решил, что я никогла БД не видел ?
Когда речь о БД, ты вроде понимаешь из за чего расходуется пространство.
А когда о БД в памяти, ты начинаешь рассказывать что все программисты дураки ибо плохо пишут.
PD>Оптимизацию под быстродействие совсем не всегда необходимо сочетать с дополнительным расходом памяти. Можно изменить алгоритм, лучшим способом разместить данные и т.д.
Алгоритмы это долгосрочная стратегия и иногда даже проф. математики не могут предложить хорошего решения.
А заказчик просит хоть 10% но прямо сейчас.
I>>Да, примерно так. И меня абсолютно не удивляет, почему Хром жрет память. PD>Дв и меня не удивляет. Только вот причины этого неудивления у нас с тобой различны
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Mamut, Вы писали:
M>> H>Что ты имеешь ввиду, когда говоришь "умер"? В момент трансляции или в момент исполнения? Я тебе могу показать семилетней давности интерпретатор, правда не JavaScript, который 4Мб скрипт (синтетический правда) транслирует за 2 сек, а интерпретирует (исполняет т.е.) за 60 мсек (без джитов и прочего).
M>> Еще скажи, что этот интерпретатор использовался в IE5.5/IE6, например (как раз семь лет тому назад).
H>Причем тут IE вообще? Речь о интерпретаторах и их качествах Ты говоришь, что с течением времени они стали круче, и оправдываешь этим возросший расход памяти (а что еще ты хотел сказать говоря об умирающем на 2Mb скрипте интерпретаторе). Я тебе говорю, что и семь лет назад можно было не умирать на больших скриптах, если писать интерпретатор нормально.
Охохонюшки. В контексте данной подветки:
— я не оправдываю возрост памяти
— интерпретаторы в браузерах улучшились
— обхемы загружаемых в браузеры данных возрасли на порядки
Здравствуйте, Mamut, Вы писали:
M> H>Причем тут IE вообще? Речь о интерпретаторах и их качествах Ты говоришь, что с течением времени они стали круче, и оправдываешь этим возросший расход памяти (а что еще ты хотел сказать говоря об умирающем на 2Mb скрипте интерпретаторе). Я тебе говорю, что и семь лет назад можно было не умирать на больших скриптах, если писать интерпретатор нормально.
M> Охохонюшки. В контексте данной подветки: M> — я не оправдываю возрост памяти M> — интерпретаторы в браузерах улучшились M> — обхемы загружаемых в браузеры данных возрасли на порядки
Как раз в контексте треда идет спор об оправданности высокого потребления Твои слова о размерах скриптов прозвучали, как аргумент в защиту позиции оправдывающей высокое потребление. Первый раз ты вообще сказал:
На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
Из этого, как бы, должно следовать, что коли сегодняшние интерпретаторы не умирают от 178Kb скриптов утащив при этом за собою всю систему (твоя гипербола вышла на орбиту ) то это должно их оправдывать. Вот у меня тут не срастается...
M>>>>при чем тут HTML страница? Открою страшную тайну: js- код может подгружаться из внешних файлов PD>>>А я и не знал .
M>>Тогда почему ты заострил внимание на «одной HTML-странице в 500 килобайт»?
PD>Потому что, как правило, страницы HTML вместе с внедренным в него или иначе вставленным JS имеют размер, намного меньше. О том, что размер вырос на порядки, говорить все же не приходится. Вырос, не спорю, в несколько раз, но не на порядки.
Минимум на порядок
M>>>>inbox GMail'а загружает аяксом — внимание — 2.8 MB данных: M>>>>http://files.rsdn.ru/9088/gmail%20ajax.png
PD>>>Да уж. Gmail это умеет
M>>Да и не только GMail.
PD>Между прочим. Компиляция обычных статических языков, как я уже не раз тут замечал, вполне может идти на нескольких Мб. Доказательство простое — она шла, и с весьма приличной скоростью при памяти в Мбайты и частоте в десятки-сотню MHz и без многоядерности. Это сейчас просто начали памятью бросаться. А Язык С++ от времен BC 5.0 до нашего времени не менялся практически. А тут, видите ли, чтобы откомпилировать 2.8 Мб сорсов, нужна сотня Мб. При том, что язык довольно простой. Что же это такое, кроме как халтурное программирование ?
Фигня, что этот скрипт не только компилируется, но и выполняется? Или мне надо взять Фотошоп, запустить его, увидеть, что он жрет немерянно памяти и сделать вывод о фиговом компиляторе?
M>>>>И загружается там не банальный JSON, а
M>>>>http://files.rsdn.ru/9088/gmail%20ajax%202.png PD>>>
M>>Улыбки улыбками, но там грузится не 50 килобайтов скриптов, а почти 3 мегабайта.
PD>Да пусть и 3! Вот возьми BC 3.1 в MS-DOS , процессор Пентиум-100, ОП чтобы было 4 Мб, а лучше 8 и откомпилируй эти 3 Мб. Со свистом. При том, что там еще и .h файлы включаются и компилируются, если отключены predcompiled headers. Ты будешь утверждать, что JS сложнее C++ ?
Повторю во второй раз: «Фигня, что этот скрипт не только компилируется, но и выполняется?»
M>>>>На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
PD>>>Я все же одно не пойму. ТурбоПаскаль 1987 года тихо и спокойно переварил бы файл на 177.27 Кб при 640 Кб ОП и не почесался бы. Подумаешь, 177 Кб. Ну ладно, на тебе в 10 раз больше. А в 100 зачем ? Что за чудная такая задача — интерпретатор с несложного, в общем-то, языка, к тому же большая часть кода в котором есть вызовы браузера (всякие document.open и window.on_не_знаю_что)
M>>Javascript кажется несложным. Тут тебе и динамика и функции высшего порядка и замыкания и eval.
PD>Ай-яй-яй. На замыкания с eval нужно 100 Мб. А динамика — так она вроде как в любом интерпретаторе потенциально возможна, на то он и интерпретатор. К примеру, в той же FoxPro на 1 Мб в DOS-времена были переменные, тип которых изменялся во время выполнения. Что тут такого-то ?
Повторю в третий раз: «Фигня, что этот скрипт не только компилируется, но и выполняется?» Что тебя зациклило на компиляции? Компиляция на современных реализациях Яваскрипта занимает доли секунды, а то и быстрее.
А те самые «вызовы» браузера — не настолько простая и нересурсоемкая операция, как тебе кажется. В том же GMail'е идет постоянная манипуляция DOM'ом (который сам по себе не является особо эффективной структурой для хранения). Банальный insert/show отожрет у тебя или память или процессор (а вернее, и то и другое), и Javascript тут вообще не причем. Курить reflow и redraw/repaint.
>>Но его обработка ускоряется. Повторю, что интерпретатор 10-летней давности умер бы на 2 мегабайтах скриптов. PD>Значит, так хорошо умели (умеют) писать эти интерпретаторы
Повторю в четвертый раз: «Фигня, что этот скрипт не только компилируется, но и выполняется?».
M>>>>Так что с порядками все в порядке.
PD>>>Не совсем
M>>Угу. Порядок — это степень 10.
PD>Именно. На порядок — в 10 раз. На 3 порядка — в 1000. Если было 50 Кб — давай сюда HTML с JS на 50 Мб, вот это и будет 3 порядка. Только имей в виду, что у меня канал номинально 10 Мбит, так что загрузится твой JS хорошо если через минуту
M>>Возьмем сначала: M>>
M>> На порядки — это что, в 100 или 1000 раз ? Если 10 лет назад на странице было 5 Кб, то сейчас 500 или 5000 ?
M>>10 лет тому назад 5 килобайт.
PD>А сейчас так-таки сплошь и рядом 5 Мб ? Между прочим, на его загрузку нужно 5 сек у меня, а если скорость 1-2 Мбит ?
Не пять, но 3. На том же GMail'е. На том же facebook'е. на том же Твиттере. Ты думаешь, что, раз загрузив 100 килобайт на том все? Любой твой поиск в Google Instant бросает в тебя сотню-другую килобайтов яваскрипта. Любой чих на Фейсбуке — аналогично. Рассказать тебе, какие сайты сейчас самые популярные в мире или сам догадаешься?
M>>RSDN: 50 килобайт. Разница на порядок. M>>google.com: 188-361 килобайт. Разница на два порядка.
PD>На 2 порядка будет все же 500, а не 188.
M>>gmail.com: 2800 килобайт. Разница на три порядка.
PD>И здесь все же надо 5000. Ты с порядками поаккуратнее
M>>
M>>Все в порядке с порядками. Более того, если 10 лет тому назад две-три страницы с большими/активными яваксриптами могли намертво и надолго завесить браузер, то сейчас не проблема иметь в одном окне gmail, в другом — твиттер, в третьем — facebook и т.д. и т.п., а в нцатом спокойно что-нибудь искать в google instant (да еще и с предосмотром страниц).
PD>Счастье-то какое! Помню, в 2000-м был у меня Пентиум-3, памяти 256 Мб, тактовая 667 MHz. И работал в ней Netscape Navigator 4.7. В одном окне была почта, в другом web, а еще был composer и не помню что еще. И ничего они не вешали. Вот поиска в гугле не было, потому что не было гугла. Но поиск на altavista (я тогда ей пользовался) или rambler — без проблем.
Угу. И почта, видимо была уровня GMail'а и поиск тоже был уровня Google Instant, ага. Еще навреное уже тогда Facebook существовал в нынешней инкарнации — с динамикой, мгновенными нотификациями и т.п. Ага-ага, верю.
PD>А всего-то 256 Мб... Получается, что для того, чтобы от 5 Кб JS перейти к 500 Кб, надо объем ОП увеличить в 16 раз, тактовую в 5, ядер в 4 ! Да это просто чудовище какое-то, ваш JS .
Угу, только проблема сейчас уже не столько в JS, сколько DOM'е браузеров.
M>> H>Причем тут IE вообще? Речь о интерпретаторах и их качествах Ты говоришь, что с течением времени они стали круче, и оправдываешь этим возросший расход памяти (а что еще ты хотел сказать говоря об умирающем на 2Mb скрипте интерпретаторе). Я тебе говорю, что и семь лет назад можно было не умирать на больших скриптах, если писать интерпретатор нормально.
M>> Охохонюшки. В контексте данной подветки: M>> — я не оправдываю возрост памяти M>> — интерпретаторы в браузерах улучшились M>> — обхемы загружаемых в браузеры данных возрасли на порядки
H>Как раз в контексте треда идет спор об оправданности высокого потребления Твои слова о размерах скриптов прозвучали, как аргумент в защиту позиции оправдывающей высокое потребление. Первый раз ты вообще сказал: H>
На скриншоте — аякс запрос на 177.27 KB. Интерпретатор 10-летней давности умер бы, утащив за собой всю систему. Сейчас же у меня Safari даже не чешется, загружает и все.
Это к тому, что Павел не верил, что сейчас передаются огромное количество данных на веб-страницы.
H>Из этого, как бы, должно следовать, что коли сегодняшние интерпретаторы не умирают от 178Kb скриптов утащив при этом за собою всю систему (твоя гипербола вышла на орбиту ) то это должно их оправдывать. Вот у меня тут не срастается...
Павел почему-то зациклился на компиляции. помимо компиляции есть еще и выполнение этих скриптов. Которые не работают в вакууме, а манипулируют тем же DOM'ом, например. И работают сейчас с тем же DOM'ом намного интенсивней и одновременно эфективней, чем 10 лет тому назад. Не говоря уже о том, что и сама структура страниц значительно усложнилась
) то это должно их оправдывать. Вот у меня тут не срастается...
