Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 95
Интересно, за счёт чего оно (AFOM) работает при отключенном файле подкачки?
Тут нужно углубиться в структуру памяти виндовс. Виртуальная память проецируется в реальную небольшими блоками, страницами. Для каждой страницы хранится её состояние и адрес в виртуальном адресном пространстве. Страницы, про которые я и Inversion говорим, что они «сбрасываются в подкачку», на самом деле в эту самую секунду никуда не перемещаются, они помечаются как освободившиеся, но по прежнему продолжают содержать страницы виртуальной памяти. Если эти страницы в скором времени понадобятся приложению, их не придется ниоткуда доставать, они просто снова будут помечены как работающие. Если же память понадобится другому приложению (или даже под дисковой кеш), в первую очередь система сбросит в подкачку именно эти блоки. Если в системе нет файла подкачки, то они вообще никуда не перемещаются ни при каких обстоятельствах, у них только меняется маркет туда-сюда. Т.е. происходит бесполезная работа.
Спасибо!
Вот и ответ на вопрос, который у меня возникал: «почему, когда в Task Manager видно, что показатель Mem Usage сбросился до 0, физически память не освобождается, что можно проследить в том же TaskInfo».
И вот почему получается, что всё то, что активно используется сразу не тормозит (так как те страницы сразу же помечаются как такие, что используются), а вся редкая функциональность со временем открывается с задержкой (так как соответствующие ей страницы остаются с пометкой для сбрасывания в своп и таки попадают туда со временем).
Вот и ответ на вопрос, который у меня возникал: «почему, когда в Task Manager видно, что показатель Mem Usage сбросился до 0, физически память не освобождается, что можно проследить в том же TaskInfo».
И вот почему получается, что всё то, что активно используется сразу не тормозит (так как те страницы сразу же помечаются как такие, что используются), а вся редкая функциональность со временем открывается с задержкой (так как соответствующие ей страницы остаются с пометкой для сбрасывания в своп и таки попадают туда со временем).
Гм, я бы сказал что структура памяти виндоус и ее отображение в Таск Менеджере весьма запутанное!
p.s. Того же эффекта можно добиться, запустив какое-нибудь памятеемкое приложение, все остальные приложения вытесняются в своп и занимают рекордно мало памяти.
p.s. Того же эффекта можно добиться, запустив какое-нибудь памятеемкое приложение, все остальные приложения вытесняются в своп и занимают рекордно мало памяти.
А Вы, случайно, не эксперт по выделению памяти в Linux/*BSD?
Интересно как там выяснить объём использованой памяти. Ну и вообще работу с памятью в этих ОС.
Общие принципы понятны — про shared libraries, virtual memory и т.д., хотелось бы развёрнутый ответ
Интересно как там выяснить объём использованой памяти. Ну и вообще работу с памятью в этих ОС.
Общие принципы понятны — про shared libraries, virtual memory и т.д., хотелось бы развёрнутый ответ
Я встречал информацию о том, что при таких движениях активируется сборщик мусора. Возможно именно это приносит результат без участия свопа. Но фактом остается то, что при наличии свопа он используется этой операцией очень сильно.
Он ест столько памяти из-за плагина который написан криво. Чистый фокс бесз единого плагина отъедает 200-350 мб за два дня непрерывной работы, с 10-20 вкладками. С плагинами (32 штуки) работает где-то сутки, за это время отжирает до 800мб оперативы и становится невозможно работать, приходится его перезапускать. К сожалению нет ни знаний, ни времени искать какой из плагинов — виновник этого безобразия.
А отключение плагина, но не деинсталяция, помогает?
Интересуте даже не отжирание памяти, а тормоза в работе JS. Последнее время у меня с этим какие-то косяки.
Интересуте даже не отжирание памяти, а тормоза в работе JS. Последнее время у меня с этим какие-то косяки.
FF 3.5.3, 41 плагин, 11(минимум) — 30 закладок, 3 дня работы. Памяти кушает 400Мб при старте и в конце недели. 400 Мб — это не мало, но утечек, вроде как, не наблюдается. Когда был FF 2.x, памяти он отжирал за 2 гига.
Причина — фаерфокс во многом написан на помеси яваскрипта и XUL (типа CSS/HTML для интерфейсов) — а это очень неэффективный способ, так как каждый узел дерева DOM я подозреваю, требует кучи взаимосвязанных структур для хранения информации о себе. Ксатти. манипуляция этими структурами, обход дерева — тоже не самые быстрые операции. Обновление дерева (при вставке/изменении аттрибутов хотя бы одной ноды) — вообще ад, надо обновить свойства этой ноды, указатели на соседние и родительские ноды, вычислить ее css-стиль, обновить хеши id и class элементов, возможно, также, сбросить какие-то кеши. Если нода отображается на экране, требуется обновить часть экрана, а если изменились размеры или положение, то и сделать reflow (пройтись по всем нодам-потомкам и нодам, следующим за измененной, и вычислить их новое положение, а возможно и обновить их стили). Я бы в жизни не стал писать приложение на этих технологиях.
Надеюсь, из описания выше понятно, что DOM следует обновлять одной-двумя операциями, или сменой css-класса, но уж точно не в цикле.
Расширения к фаерфоксу, из-за которых он начинает еще больше есть память — очевидно, написаны непрофессионально, и текут.
Надеюсь, из описания выше понятно, что DOM следует обновлять одной-двумя операциями, или сменой css-класса, но уж точно не в цикле.
Расширения к фаерфоксу, из-за которых он начинает еще больше есть память — очевидно, написаны непрофессионально, и текут.
А по какой причине был выбран именно этот метод работы интерфейса если он так неэффективен?
весьма попсовое мнение. IEкапец предрекали в первый год выхода firefox. А не наступил он до сих пор.
вот у меня сейчас
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091027 Minefield/3.7a1pre
никаких ОТДЕЛЬНЫХ процессов на вкладку не наблюдаю.
не подскажете как увидеть?
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091027 Minefield/3.7a1pre
никаких ОТДЕЛЬНЫХ процессов на вкладку не наблюдаю.
не подскажете как увидеть?
Хочется всё-таки приблизить светлое будущее, в котором у меня файрфокс не будет отъедать гектар оперативки. Мне её не жалко, в ноутбуке их целых четыре, но это неприлично как-то на 10 открытых окон, из которых только гуглопочтовик реально большой, жрать столько оперативки.
у меня 66 активных расширений, при 20 открытых вкладках Фокс отжирал где-то 400-500 метров оперативы.
Фиг знает, я грешу на Firebug + Web Developer Tools.
На самом деле абсолютная величина зависит от количества RAM в системе.
Уберите три гига из четырех, и вы увидите, как Firefox на тех же задачах, с теми же плагинами, и с теми же открытыми страницами, будет при работе занимать в памяти меньше места.
Уберите три гига из четырех, и вы увидите, как Firefox на тех же задачах, с теми же плагинами, и с теми же открытыми страницами, будет при работе занимать в памяти меньше места.
Вот такой наборчик, 4 гига оперативы. 400-500 оперативы — это, конечно, без AFOM, с ним меньше.
При небольшом количестве вкладок, работает периодический перезапуск браузера (при условии, что у Вас включено сохранение открытых вкладок). Это займёт секунд 10-20, но зато гарантировано работает лучше любого сборщика мусора :)
Возможно, это ещё и потому, что у меня он фактически неделями не закрывается, потому что ноубук у меня сваливается в Hibernate, и я перезапускаю браузер только когда мне нужно поставить апдейты какие-то.
«Да кто этим пользуется!»(с)
Расширения — это не только JS. Там на самом деле винигрет из JS, который обращается к объектам XPCOM (обычно скомпилированные бинарники), работает с XUL и т.д. Я так понимаю, что во всей этой каше не так просто разобраться.
Нет, неправда. Плагин може создать нечаянно/по глупости автора глобальную переменную (типа window.someVar) и прицепить к ней указатель на ноду — теперь, даже после закрытия страницы, эта нода и все ее потомки будут жить в памяти.
Также, автор плагина, может «для ускорения работы» сделать долгоживущую переменую-кеш, по типу jQuery, который кеширует поиск элементов по селектору, типа
function someFunc(arg)
{
if (!window.cache[arg])
{
window.cache[arg] = someFuncHelper(arg);
}
return window.cache[arg];
}
Такой «кеш» никогда не будет уменьшаться в размерах.
Вот кстати еще одна причина избегать сборщиков мусора :) Муть все это.
Также, автор плагина, может «для ускорения работы» сделать долгоживущую переменую-кеш, по типу jQuery, который кеширует поиск элементов по селектору, типа
function someFunc(arg)
{
if (!window.cache[arg])
{
window.cache[arg] = someFuncHelper(arg);
}
return window.cache[arg];
}
Такой «кеш» никогда не будет уменьшаться в размерах.
Вот кстати еще одна причина избегать сборщиков мусора :) Муть все это.
А у меня 8 гб ОЗУ, мне нужен этот «аддон»?
Работаю часто с google maps, через несколько минут в firefox работать невозможно. Зависает все на пять секунд с интервалом в 30.
Перехожу постепенно на chrome…
А без любимых плагинов firefox не firefox :)
Перехожу постепенно на chrome…
А без любимых плагинов firefox не firefox :)
По вашей логике, хром, который без плагинов, фаерфокс?
Главная фича фаерфокса в аддонах и полной кастомизации под пользователя, расширяемости. А без главной фичи – это уже будет не фаерфокс, а совершено другой продукт.
Фаерхоксом ему небыть, да и не надо. Говорю что перехожу постепенно… Ищу удобные плагины (которых мало)… пытаюсь перестроиться. А по моей логике ничего не проверялось еще…
Хочу посмотреть как будет вести себя хром…
Хочу посмотреть как будет вести себя хром…
Последний фаерфокс + 23 аддона = через пару часов работать невозможно. Помогает перезапуск.
За памятью не слежу. Из 4 гигов обычно свободно бывает 1 – 1.5 гигабайта, поэтому проблем с памятью не бывает. Фаерфокс сжирает 15-20% моего c2d 2.2ghz, это меня достаточно сильно огорчает.
Регулярно делаю базе sqllite — vacum.
Но считаю, что тормоза вызваны, тем, что история посещений у меня хранится 1000 дней, т.е. не очищается совсем.
За памятью не слежу. Из 4 гигов обычно свободно бывает 1 – 1.5 гигабайта, поэтому проблем с памятью не бывает. Фаерфокс сжирает 15-20% моего c2d 2.2ghz, это меня достаточно сильно огорчает.
Регулярно делаю базе sqllite — vacum.
Но считаю, что тормоза вызваны, тем, что история посещений у меня хранится 1000 дней, т.е. не очищается совсем.
Кроме расширений которые чистят память, очень нехватает аддонов для профилирования использования памяти. Есть 1-2, но в весьма зачаточном состоянии и толкового там мало что можно получить — идеал, когда можно будет точно определить какой участок кода/объект ответственен за ххх памяти, а не гадать с бубном. И документации по интеракции жаваскрипт-память, также не хватает. Буду признателен если кто-то в комментариях подкинет ссылок на эту тему.
Я разработчик админки построенной на базе extjs, практически вся визуальная часть построена динамически при помощи жаваскрипта. Это очень удобно, т.к. я пишу код виджетами и готовыми классами, а не заморачиваюсь низкоуровневыми дом операциями или писать вручную хтмл. Но в процессе работы (фаирбаг открыт постоянно), лиса может отожрать до 1-1.5 гигов памяти. Каждый рефреш страницы — +10 мегов. Казалось бы, но почему, при переходе на новую страницу (или рефреш), лиса не освобождает память тех страниц, которые уже нет (то есть предыдущей скажем)?
Я разработчик админки построенной на базе extjs, практически вся визуальная часть построена динамически при помощи жаваскрипта. Это очень удобно, т.к. я пишу код виджетами и готовыми классами, а не заморачиваюсь низкоуровневыми дом операциями или писать вручную хтмл. Но в процессе работы (фаирбаг открыт постоянно), лиса может отожрать до 1-1.5 гигов памяти. Каждый рефреш страницы — +10 мегов. Казалось бы, но почему, при переходе на новую страницу (или рефреш), лиса не освобождает память тех страниц, которые уже нет (то есть предыдущей скажем)?
> Казалось бы, но почему, при переходе на новую страницу (или рефреш), лиса не освобождает память тех страниц, которые уже нет (то есть предыдущей скажем)?
В основном из-за этих параметров (about:config):
browser.sessionhistory.max_total_viewers
browser.sessionstore.max_tabs_undo
Чем они выше, тем больше расходуется оперативки, чтобы можно было быстро вновь открыть закрытую вкладку и возвращаться назад в истории.
В основном из-за этих параметров (about:config):
browser.sessionhistory.max_total_viewers
browser.sessionstore.max_tabs_undo
Чем они выше, тем больше расходуется оперативки, чтобы можно было быстро вновь открыть закрытую вкладку и возвращаться назад в истории.
Очевидно, кто-то (фаербаг? маленькая богом забытая статическая переменная в одной из функций Gecko?) держит указатель на ноду/функцию/переменную из страницы (со всеми ее потомками), и не дает ее освободить.
Кстати, функции в яваскрипте являются замыканиями, так что они тоже могут тянуть за собой приличный хвост. мне эта черта яваскрипта всегда не нравилась.
p.s.
> Я разработчик админки построенной на базе extjs
А нормальную, на проверенных временем технологиях, сделать нельзя? Убил бы всех авторов аяксов и прочей тяжелой, тормозной, вечноглючащей фигни.
Кстати, функции в яваскрипте являются замыканиями, так что они тоже могут тянуть за собой приличный хвост. мне эта черта яваскрипта всегда не нравилась.
p.s.
> Я разработчик админки построенной на базе extjs
А нормальную, на проверенных временем технологиях, сделать нельзя? Убил бы всех авторов аяксов и прочей тяжелой, тормозной, вечноглючащей фигни.
> А нормальную, на проверенных временем технологиях, сделать нельзя? Убил бы всех авторов аяксов и прочей тяжелой, тормозной, вечноглючащей фигни
А я, с удовольствием из бластерного пистолета, поубивал бы тех, кто делает такие луддитские заявления.
Вечноглючное, тормозящее — ни в коей мере. Если в браузерах ускорят дом операции, а не жаваскрипт тасовки переменных, дадут внятные мануалы почему использует цпу/рам и т.д — будет хорошо. А при хороших средствах профилирования, можно довести до кондиции все что угодно. Это как раз то, к чему я намекал. Технологии не могут жить без соответствующей инфраструктуры, которые их обеспечивают.
А я, с удовольствием из бластерного пистолета, поубивал бы тех, кто делает такие луддитские заявления.
Вечноглючное, тормозящее — ни в коей мере. Если в браузерах ускорят дом операции, а не жаваскрипт тасовки переменных, дадут внятные мануалы почему использует цпу/рам и т.д — будет хорошо. А при хороших средствах профилирования, можно довести до кондиции все что угодно. Это как раз то, к чему я намекал. Технологии не могут жить без соответствующей инфраструктуры, которые их обеспечивают.
> Вечноглючное, тормозящее — ни в коей мере
Вот вещи, которые работают на нормальных HTML-страницах, но как правило, не работают, в новомодных аяксах/флешах:
1) Кнопка «назад/вперед»
2) Букмарки
3) Кнопка «Стоп»
4) Индикатор прогресса браузера (ну это я уже придираюсь ;) )
5) Кнопка «Обновить»
6) Ctrl + клик, или «Открыть в новой вкладке» (вот за это — не только бы убивал, но и четвертовал перед этим)
7) Страницы грузятся и работают медленнее
8) Unusable w/o javascript, меньше спектр поддерживаемых устройств, не работает через веб-прокси или анонимайзер
9) Контент хуже индексируется поисковиками
10) Глупо дублировать имеющийся функционал — а это и делают всякие jQueryModalWindowPlugin.
Это я с ходу за пару минут насчитал, на это я натыкался и как разработчик. и как пользователь. А на чем оснвоана ваша приверженность? На том, что это модно?
> Если в браузерах ускорят дом операции
Их в принципе очень сложно ускорить, единственный способ — делать как можно изменений, т.е. делать все одной операцией (сменой className, или встакой данных через innerHTML). Стараться делать изменения при display:none. Структура DOM довольно-таки сложная, и каждое (!) изменение вызывает обновление разных хешей, возможно сброс кешей, изменение свойств, перерисовку части экрана, а иногда и reflow.
Вот вещи, которые работают на нормальных HTML-страницах, но как правило, не работают, в новомодных аяксах/флешах:
1) Кнопка «назад/вперед»
2) Букмарки
3) Кнопка «Стоп»
4) Индикатор прогресса браузера (ну это я уже придираюсь ;) )
5) Кнопка «Обновить»
6) Ctrl + клик, или «Открыть в новой вкладке» (вот за это — не только бы убивал, но и четвертовал перед этим)
7) Страницы грузятся и работают медленнее
8) Unusable w/o javascript, меньше спектр поддерживаемых устройств, не работает через веб-прокси или анонимайзер
9) Контент хуже индексируется поисковиками
10) Глупо дублировать имеющийся функционал — а это и делают всякие jQueryModalWindowPlugin.
Это я с ходу за пару минут насчитал, на это я натыкался и как разработчик. и как пользователь. А на чем оснвоана ваша приверженность? На том, что это модно?
> Если в браузерах ускорят дом операции
Их в принципе очень сложно ускорить, единственный способ — делать как можно изменений, т.е. делать все одной операцией (сменой className, или встакой данных через innerHTML). Стараться делать изменения при display:none. Структура DOM довольно-таки сложная, и каждое (!) изменение вызывает обновление разных хешей, возможно сброс кешей, изменение свойств, перерисовку части экрана, а иногда и reflow.
> 1) Кнопка «назад/вперед»
> 2) Букмарки
Работает отлично, смотрите скажем как работает гуглопочта. Используеться # в url для задания внутреннего адреса.
> 5) Кнопка «Обновить»
При реализации пунктов 1-3 и это работает, путем тех же #.
> 3) Кнопка «Стоп»
И кнопка ESC останавливает ажакс. В той же гуглопочте можно увидеть, но там они это воспринимают как ошибку и через n времени повторяют запрос, но в целом можно этого и не делать, вот и полная остановка.
4) Индикатор прогресса браузера (ну это я уже придираюсь ;) )
Да тут их просто море можно навешать и более подробней притом.
6) Ctrl + клик, или «Открыть в новой вкладке» (вот за это — не только бы убивал, но и четвертовал перед этим) реализуются при помощи пунктов 1-3.
7) Страницы грузятся и работают медленнее
Очень голословно. Да если дохрена жаваскрипта и т.д., то может, но кто сказал что это не поддается оптимизации?
8) Unusable w/o javascript, меньше спектр поддерживаемых устройств, не работает через веб-прокси или анонимайзер
Тоже очень голословно. При жестоко настроенных прокси/анонимайзерах можно и обычный хтмл поломать нафиг. Да и это в большинстве не таргет группа.
Поддерживаемые устройства? Смартфоны, айфоны — жаваскрипт поддерживают. Если нужна универсальная поддержка всего, да, можно и без жаваскрипта. Но это требует конкретной задачи и конкретного под нее решения.
9) Контент хуже индексируется поисковиками
Тоже весьма специфично для задачи. Зачем моей админке сео-оптимизация? Правильно, нахрен. А вот сайтам которые ею управляются, да нужна. Но там mixed, основной жаваскрипт только на форме заказа.
10) Глупо дублировать имеющийся функционал — а это и делают всякие jQueryModalWindowPlugin.
Окно выбора файла или алерты, очень классные. Нифига нельзя настроить, а алерт вообще заставляет браузер остановиться полностью, включая другие вкладки.
Теперь из личного опыта.
Первые версии админки были без жаваскрипта и т.д. Можно было в linkse открывать и делать работу. Заказчик задавал как он хочет видеть интерфейс. Одним из условий было видеть все и сразу, без буржуйских «пагинаций». В итоге список сайтов и опций управления к ним генерировал хорошую страничку «на таблицах» весом под мегабайт-два. Сервак где была админка имел дико низкую скорость отдачи, где-то под 100кб/сек. Каждый рефреш (а также субмит) заставлял ждать по 1-2 минуте. В итоге ему был предложен вариант с аджаксом. То есть все формочки загружались по 10 штук за запрос, а сабмит в одной из них, приводил только ее перезагрузке. Заказчик не стал вникать/понимать в то как работает ажакс, он понял одно — это делает сайты быстрее. И его это устроило.
> 2) Букмарки
Работает отлично, смотрите скажем как работает гуглопочта. Используеться # в url для задания внутреннего адреса.
> 5) Кнопка «Обновить»
При реализации пунктов 1-3 и это работает, путем тех же #.
> 3) Кнопка «Стоп»
И кнопка ESC останавливает ажакс. В той же гуглопочте можно увидеть, но там они это воспринимают как ошибку и через n времени повторяют запрос, но в целом можно этого и не делать, вот и полная остановка.
4) Индикатор прогресса браузера (ну это я уже придираюсь ;) )
Да тут их просто море можно навешать и более подробней притом.
6) Ctrl + клик, или «Открыть в новой вкладке» (вот за это — не только бы убивал, но и четвертовал перед этим) реализуются при помощи пунктов 1-3.
7) Страницы грузятся и работают медленнее
Очень голословно. Да если дохрена жаваскрипта и т.д., то может, но кто сказал что это не поддается оптимизации?
8) Unusable w/o javascript, меньше спектр поддерживаемых устройств, не работает через веб-прокси или анонимайзер
Тоже очень голословно. При жестоко настроенных прокси/анонимайзерах можно и обычный хтмл поломать нафиг. Да и это в большинстве не таргет группа.
Поддерживаемые устройства? Смартфоны, айфоны — жаваскрипт поддерживают. Если нужна универсальная поддержка всего, да, можно и без жаваскрипта. Но это требует конкретной задачи и конкретного под нее решения.
9) Контент хуже индексируется поисковиками
Тоже весьма специфично для задачи. Зачем моей админке сео-оптимизация? Правильно, нахрен. А вот сайтам которые ею управляются, да нужна. Но там mixed, основной жаваскрипт только на форме заказа.
10) Глупо дублировать имеющийся функционал — а это и делают всякие jQueryModalWindowPlugin.
Окно выбора файла или алерты, очень классные. Нифига нельзя настроить, а алерт вообще заставляет браузер остановиться полностью, включая другие вкладки.
Теперь из личного опыта.
Первые версии админки были без жаваскрипта и т.д. Можно было в linkse открывать и делать работу. Заказчик задавал как он хочет видеть интерфейс. Одним из условий было видеть все и сразу, без буржуйских «пагинаций». В итоге список сайтов и опций управления к ним генерировал хорошую страничку «на таблицах» весом под мегабайт-два. Сервак где была админка имел дико низкую скорость отдачи, где-то под 100кб/сек. Каждый рефреш (а также субмит) заставлял ждать по 1-2 минуте. В итоге ему был предложен вариант с аджаксом. То есть все формочки загружались по 10 штук за запрос, а сабмит в одной из них, приводил только ее перезагрузке. Заказчик не стал вникать/понимать в то как работает ажакс, он понял одно — это делает сайты быстрее. И его это устроило.
Ну вы приводите в пример гугломейл — а все ли разработчики дотягивают до такого уровня? Что-то у меня есть ощущение, что немало тех, для кого аякс — это воткнуть какую-нибудь бесплатную jQuery-библиотеку и поменять ссылки с page.html на javascript:go('page.html');
Про использование # — есть минимум 2 проблемы. Для того, чтобы большинство перечисленных мною пунктов работало, дложно быть 2 версии сайта, аякс и HTML, и аякс должен как-то хранить путь в хеше, так? А ссылки должны вести на HTML-версию страницы, но при наличии яваскрипта — перехватываться и открываться аяксом.
1) если мы оставляем HTML-версию сайта — появляются проблемы, что у каждой страницы становится 2 адреса: /dir/page.html и /#dir/page.html (при вызове из аякса), двусмысленность же, а уж если в адресе есть GET-параметры, то дело еще хуже: стандартные параметры типа page?order=date&sort=asc обрабатываются и понимаются и браузером, и серверными скриптами (например php), а обрабатывать знак вопроса в hash — надо ручками, дублируя существующий функционал.
А вот пример еще сложнее: пользователь открыл HTML-страницу /dir/page1, а снее перешел на страницу page2 аяксом, получается адрес /dir/page1#dir/page2 — это нормально?
Я сам с этим возился, решения не нашел ((
2) Почти ни один браузер не поддерживает событие onhashchange — и тут конечно позор W3C и альтернативным браузерам, как можно вообще говорить о поддержке аякса без этого события? Решения с таймером и проверкой location.hash — такой уродливый костыль, что стыдно им пользоваться.
>> 7) Страницы грузятся и работают медленнее
> Очень голословно. Да если дохрена жаваскрипта и т.д., то может, но кто сказал что это не поддается оптимизации?
Допустим, HTML страница весит 15 Кб (несжатая), из которых 5 Кб — оформление, 10 Кб — контент. И ей не нужны тонны яваскрипта для отображения. В чем выгодя от аякса? Экономить 5 Кб (при использвоании gzip экономится 1-2 Кб) ценой кучи извратов и тяжеленного кода? Я вас не понимаю.
> В итоге список сайтов и опций управления к ним генерировал хорошую страничку «на таблицах» весом под мегабайт-два.
Извините, я не могу считать нормальным сайт, у которого в каждой странице по 2 мегабайта кода для меню. Я вообще не вижу смысла генерировать 2-Мб страницы (разве что это текст книги или мануал к MPlayer). Более того, редкий человек сможет прочесть такой объем информации за короткое время. Ошибка, очевидно, в интерфейсе вашей админки. И аякс тут — просто костыль для маскировки недостатков плохо спроектированного интерфйеса. Хотя в вашей ситуации, это наверно лучший выход.
> Берет 20кб json данных полученныъ, генерит строку мощной таблицы с графиками и данными весом в 1.5 мегабайта и сует в innerHTML. Куда уж проще. Но лиса тупит секунд 10.
Гм, а человек способен прочесть и распознать 1.5 Мб текста с ходу? Может генерировать и отображать только те данные, которые нужны пользователю? Отображать данные постепенно?
Про использование # — есть минимум 2 проблемы. Для того, чтобы большинство перечисленных мною пунктов работало, дложно быть 2 версии сайта, аякс и HTML, и аякс должен как-то хранить путь в хеше, так? А ссылки должны вести на HTML-версию страницы, но при наличии яваскрипта — перехватываться и открываться аяксом.
1) если мы оставляем HTML-версию сайта — появляются проблемы, что у каждой страницы становится 2 адреса: /dir/page.html и /#dir/page.html (при вызове из аякса), двусмысленность же, а уж если в адресе есть GET-параметры, то дело еще хуже: стандартные параметры типа page?order=date&sort=asc обрабатываются и понимаются и браузером, и серверными скриптами (например php), а обрабатывать знак вопроса в hash — надо ручками, дублируя существующий функционал.
А вот пример еще сложнее: пользователь открыл HTML-страницу /dir/page1, а снее перешел на страницу page2 аяксом, получается адрес /dir/page1#dir/page2 — это нормально?
Я сам с этим возился, решения не нашел ((
2) Почти ни один браузер не поддерживает событие onhashchange — и тут конечно позор W3C и альтернативным браузерам, как можно вообще говорить о поддержке аякса без этого события? Решения с таймером и проверкой location.hash — такой уродливый костыль, что стыдно им пользоваться.
>> 7) Страницы грузятся и работают медленнее
> Очень голословно. Да если дохрена жаваскрипта и т.д., то может, но кто сказал что это не поддается оптимизации?
Допустим, HTML страница весит 15 Кб (несжатая), из которых 5 Кб — оформление, 10 Кб — контент. И ей не нужны тонны яваскрипта для отображения. В чем выгодя от аякса? Экономить 5 Кб (при использвоании gzip экономится 1-2 Кб) ценой кучи извратов и тяжеленного кода? Я вас не понимаю.
> В итоге список сайтов и опций управления к ним генерировал хорошую страничку «на таблицах» весом под мегабайт-два.
Извините, я не могу считать нормальным сайт, у которого в каждой странице по 2 мегабайта кода для меню. Я вообще не вижу смысла генерировать 2-Мб страницы (разве что это текст книги или мануал к MPlayer). Более того, редкий человек сможет прочесть такой объем информации за короткое время. Ошибка, очевидно, в интерфейсе вашей админки. И аякс тут — просто костыль для маскировки недостатков плохо спроектированного интерфйеса. Хотя в вашей ситуации, это наверно лучший выход.
> Берет 20кб json данных полученныъ, генерит строку мощной таблицы с графиками и данными весом в 1.5 мегабайта и сует в innerHTML. Куда уж проще. Но лиса тупит секунд 10.
Гм, а человек способен прочесть и распознать 1.5 Мб текста с ходу? Может генерировать и отображать только те данные, которые нужны пользователю? Отображать данные постепенно?
А Вы не хотите посмотреть на пример RoR?
у них в контроллере (т.е. если вызывается /dir/new ) есть два обработчика — if html и if xhr.
Т.е. каким-то членом обрабатывается «Если пришёл запрос без JS, то отдаём „if html“. А если ajax — то отдаём if xhr».
Честно скажу — не вникал в тонкости, но RoR как-то обрабатывает, включил я JS в браузере или нет.
Утечку памяти не прослеживал, честно скажу.
у них в контроллере (т.е. если вызывается /dir/new ) есть два обработчика — if html и if xhr.
Т.е. каким-то членом обрабатывается «Если пришёл запрос без JS, то отдаём „if html“. А если ajax — то отдаём if xhr».
Честно скажу — не вникал в тонкости, но RoR как-то обрабатывает, включил я JS в браузере или нет.
Утечку памяти не прослеживал, честно скажу.
> Их в принципе очень сложно ускорить, единственный способ — делать как можно изменений, т.е. делать все одной операцией (сменой className, или встакой данных через innerHTML). Стараться делать изменения при display:none. Структура DOM довольно-таки сложная, и каждое (!) изменение вызывает обновление разных хешей, возможно сброс кешей, изменение свойств, перерисовку части экрана, а иногда и reflow.
Да, так и поступает extjs. Берет 20кб json данных полученныъ, генерит строку мощной таблицы с графиками и данными весом в 1.5 мегабайта и сует в innerHTML. Куда уж проще. Но лиса тупит секунд 10.
Да, так и поступает extjs. Берет 20кб json данных полученныъ, генерит строку мощной таблицы с графиками и данными весом в 1.5 мегабайта и сует в innerHTML. Куда уж проще. Но лиса тупит секунд 10.
habrahabr.ru/blogs/firefox/73946/?reply_to=2132266#comment_2132780 — вот список пунктов, если большинство из них выполняется — пользоваться можно. А в общем, надо смотреть по задаче — например, голосование за коммент аяксом — отличная вещь (но ессно, оно должно и без аякса работать :) ), вся навигация через аякс — сомнительное удовольствие.
Firefox нервно курит в сторонке, по сравнению с тем, что у меня вытворяет Total Commander под седьмой виндой:
при копировании крупногабаритных файлов (порядка десятка-двух гектар) с винта на винт, командер тихо хавает около 5 гектар памяти из 6 доступных. При этом он их хавает молча — в таск-менеджере (и не только в штатном, но и Anvir) нигде эти пять гектар не фигурируют, хотя все мониторы активности показывают, что свободно метров двести.
Я, правда, еще грешу на драйвер софтового рейда на материнке…
при копировании крупногабаритных файлов (порядка десятка-двух гектар) с винта на винт, командер тихо хавает около 5 гектар памяти из 6 доступных. При этом он их хавает молча — в таск-менеджере (и не только в штатном, но и Anvir) нигде эти пять гектар не фигурируют, хотя все мониторы активности показывают, что свободно метров двести.
Я, правда, еще грешу на драйвер софтового рейда на материнке…
Вам нужно всего одну опцию сменить в настройках:
Configuration – Options… – раздел Copy/Delete
и поставить (о) Also use big file copy mode (not using cache)
Или я ошибаюсь?
Configuration – Options… – раздел Copy/Delete
и поставить (о) Also use big file copy mode (not using cache)
Или я ошибаюсь?
Указан кеш в 10 метров для крупных файлов и 64 КБ для мелких.
Переключатель должен быть на втором методе, если Вы хотите избавиться от этого эффекта при копировании.
Там он и болтается, последние пару лет…
pic.ipicture.ru/uploads/091101/JbflNKWade.png
pic.ipicture.ru/uploads/091101/JbflNKWade.png
Значит у Вас что-то другое. У меня именно из-за первого режима такое наблюдалось.
Хотя ещё имеет значение, чем Вы смотрите. Я несколько дней назад тоже наблюдал такой эффект, но это оказался битый TaskInfo версии 8 (при копировании больших файлов оперативка забивалась до 100%). Обновил TaskInfo и оказалось, что ничего подобного не происходит :)
Хотя ещё имеет значение, чем Вы смотрите. Я несколько дней назад тоже наблюдал такой эффект, но это оказался битый TaskInfo версии 8 (при копировании больших файлов оперативка забивалась до 100%). Обновил TaskInfo и оказалось, что ничего подобного не происходит :)
Похоже это раз пятый за день, когда приходится развеивать бред и заблуждения.
Стиви, не стоило показывать бедным пользователям столько цифр, сколько в диспетчере задач windows 7, они не того думать начинают.
все мониторы активности показывают, что свободно метров двести.Свободно физической памяти 200 метров, но приложения в сумме не занимают остальное пространство? А посмотрите выше, не под буферы и кеши ли заняты не достающие 5 гигов. Вы копируете файлы, соответственно они кешируются в ОП для быстрого последующего доступа. При этом они не выделены под приложение, они находятся в кеше ОС и когда будет нужна память, легко освободятся.
Стиви, не стоило показывать бедным пользователям столько цифр, сколько в диспетчере задач windows 7, они не того думать начинают.
Может быть, это superfetch лютует? Я такое замечал под вистой с ImgBurn и uTorrent'ом — Superfetch пытался кешировать 8 гиговые файлы, особенно было весело, когда кешировался образ который записывался.
Я бы при таком раскладе сильно беспокоился за свои данные. Отлучился минут на 15 — и заново всё делай. Формы можно 'лазарем' восстановить, а с остальным не до конца проделанным не так всё просто.
по ошибке засадил about:memory в хроме :) и… был удивлен, хром показал таки About memory Measuring memory usage in a multi-process browser у них с фф что одни и те же команды? :)
сам себе и отвечу, очень поучительная страничка
googlesystem.blogspot.com/2008/09/google-chromes-about-pages.html
я например, к сожалению этого не знал :)
googlesystem.blogspot.com/2008/09/google-chromes-about-pages.html
я например, к сожалению этого не знал :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О разных плагинах и советах о «чудесном» отучении Firefox кушать оперативку