JavaScript: оператор delete создает утечку!?

Ох уж это Vanilla JS!

Насколько я понимаю, первый вариант удаляет объект, а не элемент массива. И, если я не ошибаюсь, я даже где-то видел предостережение от такого использования delete.

А я правильно понимаю, что сборщик мусора потом все же вычистил память?

Учитывая, что delete для элементов массива не меняет его длинну, это может привести к всяческим ошибкам при дальнейших операциях с этим массивом. Предпочитаю использовать splice.

Кстати, вопрос не в тему))
Как сделать чтоб мой пост был во вкладке посты?

Скажите, а для отлова утечек вы используете только стандартные средства хрома или что-то ещё?
И я правильно понимаю что вы скрупулёзно, в силу требований проекта, проверяете на утечки новые куски кода?

Прикольно, что судя по всему, если сделать вместо

delete testedObject[ i ].obj;

testedObject[ i ].obj = null;

сборщик мусора собирает эти объекты

Как Вы пользуетесь гуглом?
У меня первым результатом ссылка на StackOverflow, смотрите второй ответ по популярности в качестве разъясняющего примера.

testedObject[ i ].obj = null;

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

Прежде всего совет: не пытайтесь понять, что удаляется, а что не удаляется по графику потребления памяти — это гадание на кофейной гуще. Просто посмотрите на снапшот кучи.

Объяснение (по крайней мере для Хрома) очень простое: когда вы делаете delete testedObject[i].obj, V8 нормализует объект testedObject[i] — трансформирует его из быстрого компактного представления в медленное и раздутое представление на основе словаря, который еще и выделяется с запасом по размеру. При этом V8 не замечает, что после удаления в словаре будет пусто — и словарь (800 байтов) остается болтаться в воздухе. И так для каждого из ваших объектов.

Дополню mraleph:

После создания объектов:


После удаления филдов obj


Как видно — obj прекрасно подчистился и никаких «first»-«second»… не осталось. Но остался массив в 10 000 элементов (сам по себе занимающиий 470КБ), в каждой ячейке из которого пустой объект весом 424 Байта (почему пустой объект весит больше заполненного объяснил mraleph — полагаю потому что сказав delete testedObject[i].obj вы фактически сказали что testedObject[i] — изменяемый и вы можете захотеть впихнуть в него новых данных например а не просто обратиться к его полям в «read-only» режиме)

Все логично. В первом варианте у Вас:

testedObject = {
    1 : {
        obj : {....}
    },
    ....
    .....
}

что дает count объектов внутри testedObject, внутри каждого из которых по 1 объекту obj, то есть суммарное кол-во «значимых» объектов 2*count.

Во втором варианте у Вас:

testedObject = {
    obj : {
        1 : {
             .....
         },
          ....
          .....
    }
}

что дает внутри testedObject 1 объект obj, в котором count объектов с индексами, то есть суммарное кол-во «значимых» объектов count + 1.
То есть второй вариант изначально потребляет меньше памяти, что также можно видеть на графиках, достаточно выключить Record, а потом опять включить, чтоб увидеть конечный результат после нажатия «Заполнить массив».

С учетом комментария mraleph и комментария seriyPS можно принять, что при операции delete родительский объект «нормализуется» и в конечном счете становится не меньше N байт (как видно, зависит от системы).

Для первого варианта родительским объектом является testedObject[i] (который Вы не удаляете), для второго варианта родительским элементом является testedObject.obj, то есть в первом варианте (с «утечкой») Вы получаете в остатке:
(2*count - count)*N => count*N байт лишними
Во втором варианте Вы получаете:
(count + 1 - count)*N => N байт лишними
Как-бы логично, что count*N > N, «примерно» в count раз ;)

выше уже написали что удаляются разные вещи, но они удаляются — delete возвращает также результат операции, в обоих случаях true.

кроме того, странно видеть профайлер хрома, если баг открывают на мозилловцев.
если смотреть about:memory, то память возвращается спустя какое-то время или запуском сборщика мусора.

>> На все вопросы получены четкие ответы, это не магия JavaScript, не утечка и не браузерный баг, это особенность реализации.

Не совсем, все-таки, на мой взгляд утечка здесь есть, потому как был {}, потом {obj: {...}}, потом удалили obj через delete и получили, что размер полученного {} > начального {}, или теперь memory leak == «особенность реализации»? )
Просто у Вас некорректный пример, так как сравниваете изначально разные вещи, если уж отписывать баг, то скрипт должен быть другим, в котором будет видна утечка от «особенностей реализации».

В приведенном выше рассуждении была некая переменная N, вместо которой нужно (N + M), где:
— M — это размер пустого объекта {};
— N — размер «особенностей нормализации».
Тогда testedObject[i] должен после delete testedObject[i].obj стать размером M, а становится размером (N + M), то есть в первом варианте после «очистки» в идеале должны получить M*count, а получили (N + M)*count, а еще в куче видно, что M много больше N, что немного неправильно.

Не совсем, все-таки, на мой взгляд утечка здесь есть

Да, я согласен, это не утечка, как таковой казалась на первый взгляд, и я написал об этом. Под особенность реализации, о которых я не знал, думаю и многие другие, я имел в виду:

когда вы делаете delete testedObject[i].obj, V8 нормализует объект testedObject[i] — трансформирует его из быстрого компактного представления в медленное и раздутое представление на основе словаря, который еще и выделяется с запасом по размеру. При этом V8 не замечает, что после удаления в словаре будет пусто — и словарь (800 байтов) остается болтаться в воздухе.

зная о такой реализации оператора delete, я бы не наткнулся на такие грабли, и поста бы вообще небыло. Но пост есть, и думаю заслужиает существования, т.к. вполне вероятно многие незнаю как работает delete.