window.URL.revokeObjectURL () не освобождает память немедленно (или не освобождает вовсе)?

Я делаю интерфейс html для загрузки изображений на сервер с помощью Drag & Drop и файлов с множественным выбором. Я хочу показать картинки перед отправкой на сервер. Поэтому я сначала пытаюсь использовать FileReader , но у меня были некоторые проблемы, как в этой публикации . поэтому я изменил свой путь и решил использовать blob: url, как и рекомендации ebidel в сообщении, с window.URL.createObjectURL () и window.URL.revokeObjectURL () для выпуска объем памяти.

Но теперь у меня есть другая проблема, похожая на эту . Я хочу, чтобы клиент мог загружать 200 изображений за раз, если захочет. Но браузер вылетел из строя, и использованная память была очень высокой! Поэтому я подумал, что, возможно, одновременно отображается слишком много изображений, и я настроил систему с очередью ожидающих файлов с использованием массива, чтобы обрабатывать только 10 файлов за раз. Но проблема все еще возникает.

В Google Chrome, если я проверю chrome: // blob-internals / , файлы (которые обычно уже освобождаются window.URL.revokeObjectURL () ) освобождаются приблизительно после 8-секундной задержки.В Firefox я не уверен, но похоже, что файлы не были выпущены (я проверяю about: memory -> изображения для этого)

Мой код плохой, или это проблема не зависит от меня? Есть ли способ заставить навигаторы немедленно освобождать память? Если это может помочь, то это часть JavaScript, в которой возникают проблемы: (Извините, но я даю здесь ссылку из-за механизма спама изображений для новых участников) http://www26.zippyshare.com/v/14195278 /file.html .

РЕДАКТИРОВАТЬ

Это своего рода собственный ответ + ответ на Bennlich (слишком длинный текст для комментария)

Я понял из ответа пользователя 1835582, что я действительно могу удалить Blob / File, но пока браузер нужны изображения, он хранит их где-то в памяти (что логично). Так что именно отображение изображений (многих и тяжелых) вызывало сбои и замедления, а не метод revokeObjectURL . Более того, каждый браузер по-своему управляет памятью, что приводит к разному поведению. Вот как я пришел к такому выводу.

Во-первых, давайте попробуем, чтобы revokeObjectURL работал хорошо, на простом примере с использованием исходного кода https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Example. 3A_Using_object_URLs_to_display_images . Используя Chrome, вы можете проверить, что Blob отозван, проверив chrome: // blob-internals / или попытавшись открыть отображаемые изображения в новой вкладке, которая будет пустой. Примечание: чтобы полностью освободить ссылки на Blob, добавьте document.getElementById ("fileElem"). Value = "" .Когда несколько лет назад я разместил свой вопрос, на выпуск blob-а ушло около 8 секунд, теперь это почти сразу (вероятно, из-за улучшений в Chrome и / или улучшенном компьютере)

Затем пришло время для теста заряда. Я сделал это с сотней jpg ~ 2,5 млн. Каждый. После того, как изображения были отображены, я пролистал страницу. Произошел сбой Chrome, а Firefox работал медленно (в других браузерах не тестировался). Однако, когда я прокомментировал li.appendChild (img) , все прошло хорошо, даже с огромной кучей изображений. Это показывает, что проблемы возникают не из-за метода revokeObjectURL , который на самом деле работает правильно, а из-за отображения большого количества тяжелых изображений. Вы также можете протестировать создание простой html-страницы с сотнями тяжелых изображений и прокрутить ее => тот же результат (сбой / замедление).

Наконец, чтобы глубже изучить управление памятью изображений, в Firefox интересно изучить about: memory. Например, я видел, что когда окно активно, Firefox распаковывает изображения (изображения -> несжатая куча увеличивается), в то время как необработанные (изображения -> необработанные) всегда стабильны (относительно количества загруженных изображений). Здесь есть хорошее обсуждение управления памятью: http://jeff.ecchi.ca/blog/2010/09/19/free-my-memory .