Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Конечно непродуктивная — у меня примерно 10 лет работы с вещами вроде DOM, а у тебя всего лишь "БД R/O в памяти".
PD>Я думаю, не зная того, что я делал и не говоря толком ничего о том, что ты делаешь сам, едва ли стоит меряться.
Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>Ну почему же не может? Есть такое понятие как "пик рабочего набора", есть "частный набор", по ним вполне можно оценить аппетиты хрома по отношению именно к ФАП. Нас ведь именно это интересует?
PD>Опять ты запутался. Про рабочий набор смотри вот здесь
PD>http://rsdn.ru/forum/dotnet/1869304.1.aspx
PD>Там, конечно, не результат моих исследований, а компиляция из Соломона-Руссиновича. Если хочешь, прочти в оригинале.
Если ты про "внутреннее устройство Windows", то я ее как бы читал, если что.
PD>Коротко — рабочий набор не является вообще характеристикой процесса, а является характеристикой поведения менеджера памяти Windows. При одном и том же размере выделенной памяти (commited) рабочий набор может отличаться в разы.
А нам интересно, что происходило в ВАП процесса или как его прожорливость по памяти отразилась на других процессах?
PD>Частный набор не имеет отношения к РН. Частный набор (черт бы побрал русскую терминологию здесь, она и на английском хорошо запутана) , если ты имеешь в виду Private Bytes — это объем коммитированной не-shared ВП.
Частный набор — это не private bytes. Это Private Working Set — часть рабочего набора, включающая в себя страницы, присутствующие в ФАП и используемые только этим процессом. Другая его часть — это Shareable Working Set — часть рабочего набора, включающая в себя страницы, присутствующие в ФАП, которые могут использоваться не только этим процессом.
PD>Если коротко.
PD>Private Bytes — управляю я. Без моего ведома ни один байт не освободить.
Это столбец "Private" раздела "Virtual Memory" на скриншотах.
PD>Shared Mem — управляю я, но отчасти и система (просто потому, что шарит хотя бы код системных DLL) PD>Working Set — я совсем не управляю, могу только рекомендовать, а Windows на мои рекомендации может наплевать. PD>Поэтому первые 2 — характеристика моего процесса, а третье — совсем нет.
Эти характеристики не дают ровным счетом ничего, если рассматривать их в разрезе влияния на доступность ФАП для других процессов.
KV>>Павел, не поленись, прочти этот документ: http://www.chromium.org/developers/design-documents/sandbox , думаю это снимет большую часть вопросов. А если заинтересует глянь этот проект: http://code.google.com/p/sandboxed/ — это песочница, отцепленная от хрома для использования в собственных приложениях. А если будет совсем интересно, то тут (http://code.google.com/p/chromium/wiki/LinuxSandboxing) реализации песочниц используемые в хроме под линукс.
PD>Все смотреть не стал, глянул начало первого документа и все стало ясно. Ничего тут нового нет. На уровне 3 кольца люди пытаются создать свою архитектуру.
Да именно так.
PD>It is tempting to extend the OS kernel with a better security model. Don't. Let the operating system apply its security to the objects it controls. On the other hand, it is OK to create application-level objects (abstractions) that have a custom security model. PD>The Windows sandbox is a user-mode only sandbox. There are no special kernel mode drivers, and the user does not need to be an administrator in order for the sandbox to operate correctly. The sandbox is designed for 32-bit processes
PD>Все. Дальше можно не читать. При этих базовых посылках я заранее знаю, что они могут сделать. Они могут как угодно разделить те или иные действия или ответственность между своими процессами, создать механизмы взаимодействия, определить, кто чем занимается и т.д. На здоровье.
Как это "на здоровье"?! А где же "вау! да здравствует самый безопасный браузер в мире"?!
PD>Правда, так и остается непонятным, почему тут нужны десятки и сотни Мб. Модель безопасности Windows осталсь практически неизменной от 3.1 до XP включительно. То есть она работала так же в 1994, как сейчас, при 16 Мб памяти. Едва ли она намного проще чем то, что они сделали в Хроме. Почему же там хватало 16 Мб под всю ОС, а тут нужно 100 под один броузер ?
Ты почему-то считаешь, что речь идет только о накладных расходах, связанных непосредственно с созданием нескольких процессов вместо одного, но это не так. Вот представь, что в одном процессе (ОС) рендерер подгрузил jquery. Выполняя код, он построил развесистые и весьма тяжелые структуры, необходимые V8 для быстрого исполнения скрипта. В этот момент, ты открыл в другой вкладке еще один сайт, другой, но тоже использующий jquery. Файрфокс или опера имеют возможность использовать уже построенные для этой библиотеке бэкендовые структуры, чтобы сэкономить на памяти и времени, необходимом для их построения. Хром — не может. Поэтому он снова загрузит исходник jquery (возьмет из файлового кэша, скорее всего) и заново построит все структуры в АП процесса нового сайта.
Я говорю о подобных расходах, которые являются прямым следствием мультипроцессности и платой за безопасность.
PD>Что касается механизма целостности — это лишь небольшая пришлепка к собственно механизму безопасности Windows, едва ли его реализация увеличила размер кода, отвечающегго за безопасность, очень уж заметно.
Механизм целостности — это и есть механизм безопасности Windows (одна из его частей), а не пришлепка. И я бы не назвал реализацию практически мандатного доступа "небольшой пришлепкой"
KV>>Механизмы всегда реализуются руками или все же логика взаимодействия?
PD>Еще раз цитирую из твоей ссылки PD>Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don't. Let the operating system apply its security to the objects it controls. PD>Если они свои механизмы синхронизации сочинили вместо ивентов и семафоров, то я им сочувствую.
Они сочинили свой кроссплатформенный и безопасный RPC, если тебе будет угодна аналогия.
KV>>Ты говоришь о процессах ОС и совершенно прав. Давай теперь введем такое понятие как "хромпроцесс", не имеющее отношения к процессам ОС? PD>Маленькое замечание : хромпроцесс неизвестен ОС Windows.
И не должен быть известен. Хромпроцесс — это абстракция, позволяющая отцепить значительную часть кода от используемой в конкретном случае хромовской модели управления процессами.
PD>Поскольку ОС Windows ничего не знает о хромпроцессах, ей нет дела до этих песочниц. Можете заворачивать что угодно во что угодно — Windows на это плевать.
И?
PD>Слушай, зачем ты мне банальные вещи рассказываешь ?
Потому что ты мне тоже их рассказываешь
PD>Я это все 15 лет назад знал.
Я тоже, только лет 10 назад, к твоему сведению.
PD>Хочешь — открой несколько окон, запустив несколько процессов. Хочешь — открой несколько окон, запустив по потоку в процессе и по окну в потоке. В первом случае падение одного процесса не влияет на остальные. Во втором падает весь процесс со всеми потоками. Я это упражнение студентам лет так 10 даю (только вот окно не броузера), что тут за открытие Америки ?
KV>>А если учесть еще и то, что между некоторыми рендерами необходимо обеспечивать возможность доступа из javascript одного к DOM другого...
PD>И что ? Для этого нужно 100 Мб ? LPC/RPC/OLE/COM уже отменили ?
Под линуксом?
PD>А запросы из Word в Excel тебя не удивляют ? А вставка таблицы из Excel в окно моего приложения не удивляет ?
Если реализуешь это под линуксом, но с вордом и экселем — удивит.
KV>>Я говорил о "хромпроцессах" PD>Если речь идет о Windows, то это все равно верно.
Речь не может идти только о винде, т.к. хром кроссплатформенен.
>>И, в результате, получился движок, порвавший в клочья все существующие по скорости выполнения скриптов.
PD>Что немудрено, если принять во внимание качество исполнения их.
Что не так с качеством их исполнения? Очень качественно исполняются, на мой, дилетантский, взгляд
PD>>>И на это нужны десятки Мб ? По Кбайту оверхеда на текстовую строку ? KV>>А что ты хотел от динамического прототипного языка, который разогнали аки ту частицу в коллайдере? PD>Скорее от телеги, на которую поставили паровой двигатель, потом сделали несколько топок, посадили по кочегару у каждой и теперь вполне довольны, видя, как эта колымага несется, распугивая лошадей
Я рад, что ты понял основной принцип оптимизации исполнения динамически-типизированного кода Что, впрочем нисколько не умаляет достоинств динамической типизации (интересно, закастится сейчас сюда Wolfhound или нет?).
Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>А если учесть еще и то, что между некоторыми рендерами необходимо обеспечивать возможность доступа из javascript одного к DOM другого...
PD>И что ? Для этого нужно 100 Мб ? LPC/RPC/OLE/COM уже отменили ? И при чем тут js ? Запрос в любом случае делают не из js.
LPC/RPC/OLE/COM безбожно тормозит. Это было актуально во времена эксплорера 4.0, а сейчас уже устарело для данных задач.
JS или рендерер абсолютно не важно — доступ к DOM должен быть мгновенный и сама DOM должна работать мгновенно.
Вот ради этого люди пошли оптимизировать структуры данных под перформанс, ради этого и потребляется память — JS+DOM+рендереры.
>А запросы из Word в Excel тебя не удивляют ? А вставка таблицы из Excel в окно моего приложения не удивляет ?
Это _очень_ медленно по сравнению с тем что может JS V8.
M>>Пустой фотошоп спокойно отжирает 130 метров памяти. Компилятор С++ — гуано, однозначно.
PD>Слушай, не смеши. При чем тут компилятор ? У меня сейчас фотошоп не установлен, посмотреть не могу. Запусти на него dumpbin, а лучше Process Explorer, и посмотри, что там в этих 130 Мб. Там скорее всего несколько Мб кода (не считая, конечно, кода системных DLL), а остальное — либо массивы данных, либо ресурсы. Вот они там зачем в таком объеме для пустого фотошопа — это действительно вопрос, но уж никак не к С++, а к авторам фотошопа. Я тоже могу сделать приложение мастером VC++, добавить массив на 100 Мб и будет тебе 100 Мб памяти.
Ну ты же привязался непременно к компиляции яваскрипта
M>>Да-да. Прибегая к любимым здесь автомобильным ассоциациям: Разницы между фордом T и subaru outback'ом ты тоже не видишь. Ту же четыре колеса и руль, ага.
PD>А все же можно без аналогий объяснить, что же такое особо ценноеза последние 10 лет появилось в почте ?
Можно, например, вспомнить, интерфейс хотмэйла в 2000-м, потом открыть GMail и посмотреть на тот интерфейс, что он предлагает. Действительно совсем-совсем ничего не изменилось? ни встроенного чата, ни отсутствия перезагрузок между переходами страниц, ни схлопывания частей писем, ни драг'н'дропа, ни прозрачного выставления флагов и меток, ни прозрачного, без перезагрузки страницы, обновления инбокса по мере посупления новых сообщений — вообще ничего. То есть то, что в браузере у тебя почти полноценный аналог того же thunderbird'f — это вообще никаких изменений по сравнению с хотмейлом образца 2000-го года, ага.
>>>>Еще навреное уже тогда Facebook существовал в нынешней инкарнации — с динамикой, мгновенными нотификациями и т.п. Ага-ага, верю.
PD>>>Вот тут не знаю, ибо им не пользуюсь.
M>>не существовал, ибо существовать не мог. Любой браузер загнулся бы. PD>Хм. Я вообще с ним не знаком. Дай ссылку. Гд-то у меня валялся NN 4.7. Попробую под виртуалкой.
Да хотя бы GMail открой. Facebook.com — ссылка для facebook'а.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Хочу я в этом сообщении, о байтофобах рассказать.
Pzz>Это психотворение?
Здравствуйте, kochetkov.vladimir, Вы писали:
PD>>Коротко — рабочий набор не является вообще характеристикой процесса, а является характеристикой поведения менеджера памяти Windows. При одном и том же размере выделенной памяти (commited) рабочий набор может отличаться в разы.
KV>А нам интересно, что происходило в ВАП процесса или как его прожорливость по памяти отразилась на других процессах?
Отчасти да, так как если он прожорлив — другим мало останется. В этом-то и суть проблемы.
PD>>Если коротко.
PD>>Private Bytes — управляю я. Без моего ведома ни один байт не освободить.
KV>Это столбец "Private" раздела "Virtual Memory" на скриншотах.
Да.
PD>>Shared Mem — управляю я, но отчасти и система (просто потому, что шарит хотя бы код системных DLL) PD>>Working Set — я совсем не управляю, могу только рекомендовать, а Windows на мои рекомендации может наплевать. PD>>Поэтому первые 2 — характеристика моего процесса, а третье — совсем нет.
KV>Эти характеристики не дают ровным счетом ничего, если рассматривать их в разрезе влияния на доступность ФАП для других процессов.
Ну как же так! Вот сделаю я программу , в которой Private Bytes == 2 Gb, и где они храниться будут ? Либо в ОП, либо в свопе. Если в ОП , значит, другим меньше останется. Если в свопе — тормоза с обменом. Чудес не бывает.
PD>>Все. Дальше можно не читать. При этих базовых посылках я заранее знаю, что они могут сделать. Они могут как угодно разделить те или иные действия или ответственность между своими процессами, создать механизмы взаимодействия, определить, кто чем занимается и т.д. На здоровье.
KV>Как это "на здоровье"?! А где же "вау! да здравствует самый безопасный браузер в мире"?!
А откуда это следует ? Модель, в которой ответственность разнесена по процессам отнюдь не безопаснее, чем модель , в которой все в одном процессе. Существует много способов сделать куски кода или данных в пределах одного процесса отнюдь не равнодоступными. Иными словами, и в пределах одного процесса можно сделать так, чтобы некий код мог выполняться только этим модулем или этим потоком, то же верно для данных. А можно и наоборот — чтобы 2 процесса свободно могли иметь общие равнодоступные данные.
Так что само по себе использование одной из этих моделей ровно ни о чем не говорит, вопрос — как это написано. Можно написать хорошо один процесс и плохо — много.
PD>>Правда, так и остается непонятным, почему тут нужны десятки и сотни Мб. Модель безопасности Windows осталсь практически неизменной от 3.1 до XP включительно. То есть она работала так же в 1994, как сейчас, при 16 Мб памяти. Едва ли она намного проще чем то, что они сделали в Хроме. Почему же там хватало 16 Мб под всю ОС, а тут нужно 100 под один броузер ?
KV>Ты почему-то считаешь, что речь идет только о накладных расходах, связанных непосредственно с созданием нескольких процессов вместо одного, но это не так. Вот представь, что в одном процессе (ОС) рендерер подгрузил jquery. Выполняя код, он построил развесистые и весьма тяжелые структуры, необходимые V8 для быстрого исполнения скрипта. В этот момент, ты открыл в другой вкладке еще один сайт, другой, но тоже использующий jquery. Файрфокс или опера имеют возможность использовать уже построенные для этой библиотеке бэкендовые структуры, чтобы сэкономить на памяти и времени, необходимом для их построения. Хром — не может. Поэтому он снова загрузит исходник jquery (возьмет из файлового кэша, скорее всего) и заново построит все структуры в АП процесса нового сайта.
Ну я бы не слишком гордился таким решением. Вы вот сделайте так, чтобы при использовании общих данных быть уверенным, что при этом в обоих процесах будет надежно — вот тогда я вам свой респект и уважение выскажу. А в таком виде — не очень.
И все равно остается неясным, зачем же тут 100 Мб. Что это за такие развесистые структуры, которые имеют размер в 100 Мб.
Задам вопрос жестче. Представь себе, что увеличение объема ОП прекратилось бы, когда оно было равно , скажем, 256 Мб. Дальше не удалось. И многоядерности нет, одно ядро. В общем, в 2002 году вышли на плато.
А теперь вопрос
Утверждаешь ли ты, что в этом случае броузер по модели Хрома не мог бы быть вообще создан ?
KV>Механизм целостности — это и есть механизм безопасности Windows (одна из его частей), а не пришлепка. И я бы не назвал реализацию практически мандатного доступа "небольшой пришлепкой"
Я имел в виду, что он был добавлен после XP — пришлепка к предыдущему.
PD>>И что ? Для этого нужно 100 Мб ? LPC/RPC/OLE/COM уже отменили ?
KV>Под линуксом?
А что, под Линуксом нет ничего похожего ? Я так думаю, что есть.
PD>>А запросы из Word в Excel тебя не удивляют ? А вставка таблицы из Excel в окно моего приложения не удивляет ?
KV>Если реализуешь это под линуксом, но с вордом и экселем — удивит.
Владимир, не надо. Ты играешь на моем незнании Линукса. Там свои механизмы для этого есть, не могут не быть, потому что иначе это не ОС будет, а примитив какой-то.
KV>Речь не может идти только о винде, т.к. хром кроссплатформенен.
И что ?
PD>>Что немудрено, если принять во внимание качество исполнения их.
KV>Что не так с качеством их исполнения? Очень качественно исполняются, на мой, дилетантский, взгляд
Когда платят таким расходом памяти, это качественным называться не может.
PD>>Скорее от телеги, на которую поставили паровой двигатель, потом сделали несколько топок, посадили по кочегару у каждой и теперь вполне довольны, видя, как эта колымага несется, распугивая лошадей
KV>Я рад, что ты понял основной принцип оптимизации исполнения динамически-типизированного кода
>Что, впрочем нисколько не умаляет достоинств динамической типизации (интересно, закастится сейчас сюда Wolfhound или нет?).
Здравствуйте, Mamut, Вы писали:
M>>>Пустой фотошоп спокойно отжирает 130 метров памяти. Компилятор С++ — гуано, однозначно.
PD>>Слушай, не смеши. При чем тут компилятор ? У меня сейчас фотошоп не установлен, посмотреть не могу. Запусти на него dumpbin, а лучше Process Explorer, и посмотри, что там в этих 130 Мб. Там скорее всего несколько Мб кода (не считая, конечно, кода системных DLL), а остальное — либо массивы данных, либо ресурсы. Вот они там зачем в таком объеме для пустого фотошопа — это действительно вопрос, но уж никак не к С++, а к авторам фотошопа. Я тоже могу сделать приложение мастером VC++, добавить массив на 100 Мб и будет тебе 100 Мб памяти.
M>Ну ты же привязался непременно к компиляции яваскрипта
Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
PD>>А все же можно без аналогий объяснить, что же такое особо ценноеза последние 10 лет появилось в почте ?
M>Можно, например, вспомнить, интерфейс хотмэйла в 2000-м, потом открыть GMail и посмотреть на тот интерфейс, что он предлагает. Действительно совсем-совсем ничего не изменилось? ни встроенного чата, ни отсутствия перезагрузок между переходами страниц, ни схлопывания частей писем, ни драг'н'дропа, ни прозрачного выставления флагов и меток, ни прозрачного, без перезагрузки страницы, обновления инбокса по мере посупления новых сообщений — вообще ничего. То есть то, что в браузере у тебя почти полноценный аналог того же thunderbird'f — это вообще никаких изменений по сравнению с хотмейлом образца 2000-го года, ага.
Я вообще-то имел в виду именно десктопную почту, а в этом плане нынешний thunderbird мало чем отличается от Netscape Mail 1998 года. Ну а то, что в web-интерфейсе, потратив на это десятки и более Мб, сумели добиться почти полноценного аналога продукта десятилетней давности — говорит лишь о том, насколько подходящий инструмент (браузер) используется для этих целей. Впрочем, об этом я уже писал, повторяться не буду.
M>Да хотя бы GMail открой. Facebook.com — ссылка для facebook'а.
Попробовал GMail под NN 4.7. Не работает, но со странной дмагностикой — у меня, мол, медленный Интернет. Запускал под XP Mode, но дело не в ней, так как под IE вполне работает.
PD>>>Слушай, не смеши. При чем тут компилятор ? У меня сейчас фотошоп не установлен, посмотреть не могу. Запусти на него dumpbin, а лучше Process Explorer, и посмотри, что там в этих 130 Мб. Там скорее всего несколько Мб кода (не считая, конечно, кода системных DLL), а остальное — либо массивы данных, либо ресурсы. Вот они там зачем в таком объеме для пустого фотошопа — это действительно вопрос, но уж никак не к С++, а к авторам фотошопа. Я тоже могу сделать приложение мастером VC++, добавить массив на 100 Мб и будет тебе 100 Мб памяти.
M>>Ну ты же привязался непременно к компиляции яваскрипта
PD>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
Ну пока его нет, его и не транжирят. Вернее, транжирят столько, соклько нужно для JIT'а и runtime-оптимизаций.
PD>>>А все же можно без аналогий объяснить, что же такое особо ценноеза последние 10 лет появилось в почте ?
M>>Можно, например, вспомнить, интерфейс хотмэйла в 2000-м, потом открыть GMail и посмотреть на тот интерфейс, что он предлагает. Действительно совсем-совсем ничего не изменилось? ни встроенного чата, ни отсутствия перезагрузок между переходами страниц, ни схлопывания частей писем, ни драг'н'дропа, ни прозрачного выставления флагов и меток, ни прозрачного, без перезагрузки страницы, обновления инбокса по мере посупления новых сообщений — вообще ничего. То есть то, что в браузере у тебя почти полноценный аналог того же thunderbird'f — это вообще никаких изменений по сравнению с хотмейлом образца 2000-го года, ага.
PD>Я вообще-то имел в виду именно десктопную почту, а в этом плане нынешний thunderbird мало чем отличается от Netscape Mail 1998 года.
Там был threading, поиск и т.п.? Правда, Thunderbird плохой показатель в этом плане.
M>>Да хотя бы GMail открой. Facebook.com — ссылка для facebook'а.
PD>Попробовал GMail под NN 4.7. Не работает, но со странной дмагностикой — у меня, мол, медленный Интернет. Запускал под XP Mode, но дело не в ней, так как под IE вполне работает.
Видимо, он диагностирует не только inet, но и работу скрипта тоже.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>>Ну ты же привязался непременно к компиляции яваскрипта
PD>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
То есть не имея на то оснований, оптимизировать расход памяти в ущерб перформансу ?
Здравствуйте, Pavel Dvorkin, Вы писали:
KV>>Что не так с качеством их исполнения? Очень качественно исполняются, на мой, дилетантский, взгляд
PD>Когда платят таким расходом памяти, это качественным называться не может.
Здравствуйте, Mamut, Вы писали:
PD>>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
M>Ну пока его нет, его и не транжирят. Вернее, транжирят столько, соклько нужно для JIT'а и runtime-оптимизаций.
А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
PD>>Я вообще-то имел в виду именно десктопную почту, а в этом плане нынешний thunderbird мало чем отличается от Netscape Mail 1998 года.
M>Там был threading, поиск и т.п.? Правда, Thunderbird плохой показатель в этом плане.
Threading был, поиск был, news были, все было. Да и вообще Thunderbird лишь приятнее в интерфейсе, не более. Ничего там существенно нового нет.
PD>>Попробовал GMail под NN 4.7. Не работает, но со странной дмагностикой — у меня, мол, медленный Интернет. Запускал под XP Mode, но дело не в ней, так как под IE вполне работает.
M>Видимо, он диагностирует не только inet, но и работу скрипта тоже.
PD>>>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
M>>Ну пока его нет, его и не транжирят. Вернее, транжирят столько, соклько нужно для JIT'а и runtime-оптимизаций.
PD>А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
Честно, не знаю, сколько
PD>>>Я вообще-то имел в виду именно десктопную почту, а в этом плане нынешний thunderbird мало чем отличается от Netscape Mail 1998 года.
M>>Там был threading, поиск и т.п.? Правда, Thunderbird плохой показатель в этом плане.
PD>Threading был, поиск был, news были, все было. Да и вообще Thunderbird лишь приятнее в интерфейсе, не более. Ничего там существенно нового нет.
Ну, как я и сказал, Thunderbird вообще неудачный пример
Вот смотрю я на Mail.app под макосью... Почти пять игов писем, синхронизированных по IMAP, но хранящихся локально. С поиском, threading'ом, фильтрами, смарт-боксами, rss-читалкой и т.п. 84 мегабайта в памяти
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Слушай, ты же ясно сказал, что тебе жаль времени, потраченного на дискуссию со мной. Зачем же ты хочешь еще раз его потратить ? Я — не хочу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
Надо начинать не с килобайт и строчек, а с размера одного объекта для JS или DOM.
Этот ответ был уже и ты сказал "разобраться невозможно".
Здравствуйте, Mamut, Вы писали:
PD>>>>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
M>>>Ну пока его нет, его и не транжирят. Вернее, транжирят столько, соклько нужно для JIT'а и runtime-оптимизаций.
PD>>А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
M>Честно, не знаю, сколько
Но ведь для ТР хватало 1 Мб. А JS не сложнее.
M>Ну, как я и сказал, Thunderbird вообще неудачный пример
А что в OE лучше, кроме уязвимостей ?
M>Вот смотрю я на Mail.app под макосью... Почти пять игов писем, синхронизированных по IMAP, но хранящихся локально. С поиском, threading'ом, фильтрами, смарт-боксами, rss-читалкой и т.п. 84 мегабайта в памяти
Ну и я смотрю. Thunderbird. 2 GB писем. Хранятся локально. Поиск и прочее на месте. Размер примерно тот же.
PD>>Слушай, ты же ясно сказал, что тебе жаль времени, потраченного на дискуссию со мной. Зачем же ты хочешь еще раз его потратить ? Я — не хочу.
I>Ты распространяешь вредную идеологию.
Ты мне КПСС начинаешь напоминать. Она тоже с вредной идеологией боролась, защищала нас от от нее
Если коротко — нет вредной идеологии. Есть мнения, близкие к истине, а есть — далекие от нее. Я высказываю свое мнение, а насколько оно близко или далеко от истины — пусть другие оценят.
Здравствуйте, Ikemefula, Вы писали:
PD>>А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
I>Надо начинать не с килобайт и строчек, а с размера одного объекта для JS или DOM.
Ну вот и давай сюда этот размер. Ты же с DOM 10 лет работаешь. Давай сюда какой-нибудь пример.
Вот тебе мой пример.
Дано : набор целых чисел в количестве 10000 штук.
Объем этих данных — 40 Кб.
Решено построить из них BST
В каждом узле 4 байта под число + 8 байт под два указателя. Итого 12 байт. Возможно, при выравнивании будет 16.
16*10000 == 160000 = 160 Кб.
Так что извини, но больше 200 Кб не дам — при этой структуре.
PD>>>>>Не к компиляции, а к работе. Если в JS объявлен массив на 100 Мб — я первый потребую под него место. Но пока его нет, нечего память транжирить.
M>>>>Ну пока его нет, его и не транжирят. Вернее, транжирят столько, соклько нужно для JIT'а и runtime-оптимизаций.
PD>>>А сколько нужно под код на js размером в 50-100 Кб при том, что там нет больших массивов ? Я так полагаю, что 1 Мб должно хватить. Для ТурбоПаскаля хватало же.
M>>Честно, не знаю, сколько
PD>Но ведь для ТР хватало 1 Мб. А JS не сложнее.
А кто сказал, что JS'e не хватит?
M>>Ну, как я и сказал, Thunderbird вообще неудачный пример
PD>А что в OE лучше, кроме уязвимостей ?
Ээээ, а что такое ОЕ?
M>>Вот смотрю я на Mail.app под макосью... Почти пять игов писем, синхронизированных по IMAP, но хранящихся локально. С поиском, threading'ом, фильтрами, смарт-боксами, rss-читалкой и т.п. 84 мегабайта в памяти
PD>Ну и я смотрю. Thunderbird. 2 GB писем. Хранятся локально. Поиск и прочее на месте. Размер примерно тот же.
Правда, Thunderbird плохой показатель в этом плане.