atd Jan 27 2011 at 16:03

Вынеси мусор!

5 min

4.7K

JavaScript*

+81

Comments 39

pro100tak Jan 27 2011 at 16:11

Годно! Скажем ДА объективным тестам!

TEHEK Jan 27 2011 at 19:51

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

atd Jan 27 2011 at 22:37

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

Вот для оперы, конечно, не всё так однозначно.

b00taNik Jan 27 2011 at 16:23

Можно было даже не читать, чтобы угадать результат:

IE8 — гавно
Chrome и firefox — стабильно, вполне ожидаемо и довольно хорошо
Opera — все сделала по-своему.

И этот результат не только для этого теста, он справедлив для 95% браузерных тестов.

автору отдельное спасибо за топик, читать все равно было интересно.

taliban Jan 28 2011 at 23:05

По-своему это как? Я вот просто не понял Вы хвалите оперу или ругаете?:)

wakh Feb 15 2012 at 22:24

по-моему очень точно было подмечено, опера всё делает по-своему
это как блондинки и брюнетки — вещи несравнимые.

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

и да: «привет, мне 3Х лет и я табоголик»

taliban Feb 16 2012 at 00:34

Буквально на днях заметил что опера очень течет, выключил все расширения и она вдруг залетала =) еще говорят чистая установка помогает. А вообще опера не жадная, и обычно делится памятью. И кстати «опера всё делает по-своему», есть стандарты, опера очень щепетильно им следует (баги не считаются), и если все делать не по «ожидаемости» а по стандарту ECMA-262, то опера ведет себя вполне ожидаемо. По крайней мере я всегда пишу под фф, а под оперой проверяю, проблем (у меня) обычно нет.

wakh Feb 16 2012 at 06:05

с расширениями это мысль надо попробовать поискать «слабое звено»
жаль в матери нет больше гнёзд, я бы 8гектаров поставил и забил.

стандарты в веб-дизайне эта та штука которой все старательно избегают,
сначала разработчики, создавая браузеров, а потом дизайнеры, вставляя костыли :)

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

у меня шрифт в винде 120%, шрифты в опере ползут на 50+% сайтов, не смертельно, но, во первых, иногда неудобно, а во вторых писать «под оперу» уже не получается, так что смотрю в хроме/ФФ, а в ИЕ и Опере уже проверяю

biophreak Jan 27 2011 at 16:33

Спасибо, интересно было взглянуть.
Кстати, вроде как в хроме > 8 новый JS движок, который по заявлениям разработчиков быстрее чем старый :)
Может стоит взять какой нибудь Chromium и глянуть?

atd Jan 27 2011 at 16:45

Да, как только появится время попробую свежий хром и ИЕ9, вдруг там всё-таки сделали адекватный gc ;)

Serator Jan 27 2011 at 17:24

Тогда и Firefox 4 beta 10, аль что-то более свежее на момент тестирования, ибо в нем с движком js'а поработали очень хорошо :).

atd Jan 27 2011 at 17:40

Firefox и так лучше всех выполнил данное испытание ;)

Serator Jan 27 2011 at 17:45

Просто интересно было бы увидеть разницу по отношению к ветке 3.6.x.

widowmaker Jan 27 2011 at 19:27

Можно dev ветку хрома, у меня сейчас версия 10.0.648.6, обновляется ~ раз в неделю

hldr Jan 27 2011 at 19:32

например, ChromePlus или SRWare Iron )

mraleph Jan 27 2011 at 18:10

Если запустить Хром с флажком --js-flags="--expose-gc", то можно получить доступ к функции window.gc(), которая принудит V8 собрать весь мусор.

atd Jan 27 2011 at 22:34

спасибо. оч полезно

TEHEK Jan 28 2011 at 02:34

хм… интересная фишка. Только как на практике применить? =)

if (! 'gc' in window) alert('Пожалуйста перезапустите хром с параметрами --js-flags="--expose-gc"');

Интересно, это в node.js можно использовать?

mraleph Jan 28 2011 at 02:40

на практике не нужно звать GC, он сам придет :-)

Интересно, это в node.js можно использовать?

Можно, но опять же — не нужно.

Sannis Jan 28 2011 at 16:50

github.com/billywhizz/node-gc

На практике лучше не использовать, он и так справляется хорошо. Это последнее, о чём стоит думать.

maxshopen Jan 27 2011 at 19:17

Мне кажется вы зря статью под замком в блоге держите. Ее не увидят те, кто по каким то причинам не вступили блог «Javascript» и те, кто вообще не зарегистрирован на Хабре.

slang Jan 28 2011 at 04:27

Где же Safari? Ща маководов злых набежит!

Snipe Jan 29 2011 at 23:08

А сафари и под win есть, и довольно шустро работает, кстати. )

UFO just landed and posted this here

lahmatiy Jan 28 2011 at 11:17

В Chome и Safari разные движки javascript, в первом V8, во втором SquirrelFish. Очевидно что и сборщики мусора разные или как минимум работают отлично друг от друга.
Кстати, ошибочно считать что webkit в различных браузерах (и других программах, которые его используют) одинаковый. Во-первых разные версии. Во-вторых при имплементации webkit в продукт, часть функционала который идет в webkit «из коробки» заменяют на свою реализацию, часть отключают, добавляют новую (которую потом ошибочно считают частью webkit) т.п. То есть то какой функционал предоставляет webkit и, что немаловажно, как его предоставляет (реализация) весьма сильно зависит от приложения, которое его использует. Исходя из этого «примерно такие же результаты» для Chrome и Safari возможны далеко не всегда.

mihailt Jan 28 2011 at 14:59

это не отменяет того, что было бы интересно посмотреть результаты для safari :)

lahmatiy Jan 28 2011 at 16:25

Своим каментом я на это и намекал, видимо не очень очевидно. Заодно вставил своих 5 копеек… не знаю за что человека минусуют.
До определенного времени тоже думал, что раз webkit то везде должно быть одинаково, пока не стал получать расхождения в реализации «фич», а порой и вообще странные ситуации.
Так что тестировать в Safari все таки стоит.

sysif Jan 28 2011 at 13:36

По поводу теста для IE, от которого вы отказались в самом начале. Есть в IE там такая штука недокументированная как CollectGarbage().
Поправил вашу функцию вот так:

function test1()
{
	var sz = 100000;
	var buff = [];
	for (var i = 0; i < sz; i++)
		buff.push(i);
	alert(1);

	var buff2 = [];
	for (var i = 0; i < sz; i++)
		buff2.push(sz - i);
	alert(2);
//добавлено
	buff = null;
	buff2 = null;
	CollectGarbage();
	alert(3);
}

После этого часть памяти освободилась. Но только часть. Почему так, не понимаю

atd Jan 28 2011 at 13:41

Спасибо! Надо посмотреть на эту штуку поподробнее

lahmatiy Jan 28 2011 at 16:06

Сколько чего читал по браузерам, не разу не натыкался на этот метод в IE.
Спасибо за наводку, плюс вам в карму :)

sysif Jan 28 2011 at 17:25

Провел несколько более подробные тесты. Оказалось, что IE8 все же освобождает память.
Получился у меня примерно такой вот график (потребление памяти процессом IE):

Т.е. получается, сборщик мусора в IE8 запускается не по таймеру, а только тогда, когда ему «мало» памяти

sysif Jan 28 2011 at 17:35

В смысле, освобождает память самостоятельно. Без вызова CollectGarbage()

atd Jan 28 2011 at 17:39

А какая у вас ОС? Попробую ещё дома с другой версией и другой битностью.

sysif Jan 28 2011 at 19:00

тестировал на Win7x64, 4гб памяти

TedBeer Apr 22 2011 at 14:08

на самом деле ты поместил вызов в неправильное место :)
я поместил не внутри, а сразу после вызова функции test1() и память вернулась вся!

sysif Apr 22 2011 at 18:38

Да, это я уже потом понял

seriyPS Jan 28 2011 at 14:56

хех… В PHP так вообще нужно ВРУЧНУЮ указывать какие переменные захватить в замыкание…

brainunit Jan 28 2011 at 15:29

delete buff ничего не сделает. Оператор delete не применяется к локальным переменным, только к полям объекта.

Попробуйте так:

var obj = {};
obj.buff = [];
// test here
delete obj.buff;

atd Jan 28 2011 at 17:07

ой… ;)