окно.URL-АДРЕС.revokeObjectURL() не освобождает память сразу (или не совсем)?

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

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

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

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

редактировать

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

я понял из ответа user1835582, что я действительно могу удалить Blob/файл, но, хотя браузеру нужны изображения, он держит их где-то в памяти (что логично). Так что это факт отображения изображений (многие и тяжелые), которые дали мне сбои & замедление, а не 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 = "". Когда я опубликовал свой вопрос несколько лет назад, было около 8 секунд, чтобы выпустить blob, теперь это почти немедленно (вероятно, из-за улучшений в Chrome & / или на лучший компьютер)

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

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