авторN - это сколько? при 10 картинках по 5м - страница потребовала 200м.
В зависимости от браузера может потребоваться и 400 Мб, и 600 Мб.
По крайней мере, в статье на хабре при использовании FileReader объём потребляемой памяти для jpeg-картинок в 10-12 раз превышает размер этих jpeg-файлов (а у вас к тому же картинки занимают место в памяти в двойном, как минимум, размере - при том коде, который вы показали)

авторно ни сбоев ни вылетов не было
Раз на раз не приходится и наверняка зависит от браузера
Лично наблюдал слёты в Safari. В последнем FF генерируются ошибки в логах.

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

P.S. Иными словами, если браузер поддерживает URL API , то нет никаких причин отказываться от URL.createObjectURL()/URL.revokeObject.URL() в пользу FileReader .

В вашем случае по протоколу webSocket нельзя передать объект File вместо Blob ? Т.е. можно только из оперативной памяти передавать данные ? Если можно, то однозначно лучше передавать объект File , а превьюшки генерировать через img.src = URL.createObjectURL() с последующим URL.revokeObjectURL()

авторно кто мешает сделать подобный элемент dom, который при окончании работы просто удалится из DOM и освободит ресурсы?Освободит ресурсы, выделенные под DOM-объект, но не освободит ресурсы, выделенные под прочитанный файл (по крайней мере, сразу после удаления DOM-объекта)

авторну а размер занимаемый под src можно сразу отдать сборщику путём присвоения null.
А вы думаете, сборщик запускается сразу после исчезновения необходимости в хранении некоторых данных в оперативной памяти ?
Однозначно нет. Если присвоить ( src = null ), память не освободится. Освободится, только после того, как все превьюшки будут сгенерированы (по моим наблюдениям, через 1-10 сек либо только после закрытия/перезагрузки страницы)

авторхранение в памяти blob, это не ресурсы dom. поэтому они удаляются сразу.
А кто освобождает память, отведённую под Blob ? Тот же сборщик. А когда запускается сборщик - см. комментарий выше.

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

авторв моём варианте можно воспользоваться и base64 для отображения в src, сократив таким образом количество образов картинок. но потом рередача в текстовом формате base64 или дополнительное преобразование base64 в blob не есть более выйгрышный вариант.
ещё раз : при почти нулевой свободной памяти я не увидел больших проблем.
В вашем случае, как минимум, нужно использовать URL.revokeObjectURL() после использования объектной ссылки . На один "образ" будет меньше. Ну а почему вы на вашем конкретном браузере конкретной версии не видите никаких проблем - причины очевидно есть, но они никоим образом не связаны с вашим программным кодом. Наблюдения пользователей показывают, что при проблемы бывают и при таком коде их вероятность высока.

авторещё раз : при почти нулевой свободной памяти я не увидел больших проблем.
У меня на последней верcии FF при 3Гб оперативки (столько же свопа), когда оперативка почти полностью занята и браузеру достаётся только своп, при использовании FileReader.readAsObjectURL() из 5-10 картинок по 4Мб превью генерируются только для трети из них (и с тормозами), для остальных в логах вылезают критические ошибки. При использовании URL.CreateObjectURL()/revokeObjectURL() даже если оперативка под завяку занята, все превьюшки генерируются без ошибок и без тормозов. Пример весьма показателен.

Что касается той статьи на хабре, там действительно большие объёмы памяти потребляются. Но я проверял с FileReader.readAsObjectURL() . Действительно, потребляются большие объёмы памяти. Почему у вас нет проблем, даже при масштабном использовании свопа - можно предположить, что:

а) FileReader.readAsArrayBuffer() + Blob + ArrayBuffer => за счёт грамотной работы сборщика (а работа сборщика может зависеть и от ОС) в памяти хранится только один экземпляр данных картинки
б) эффективная и корректная работа свопа (браузер + ОС)

авторэто правильное замечание, только я не смог сообразить где его лучше вставить...В обработчике события "onload" DOM-объекта, соответствующего <img> (обработчик ставить перед image.src = ... )

Например, так:

авторблагодаря тебе я смог избавиться от jquery :) $('#pic_div').append(А при чём здесь мой код ?
И твой код, и мой - используют jquery. Впрочем, переделать на чистый javascript не сложно...

автор$(image).one('load', function(e) {...
в последних весиях (по крайней мере хрома) это стало необходимо.Не понятно, что именно необходимо ? Здесь вешается обработчик на событие "onload". В этом обработчике освобождается память, отведённая под объект, созданный методом URL.createObjectURL() . Данные действия обусловлены исключительно логикой кода, а не версией браузера.

авторнеобходимости в этом нет. потому как это urlFactory.createObjectURL(fb['pic' + fb.max]) в итоге строка, и в момент формирования основной строки это urlFactory.createObjectURL(fb['pic' + fb.max]) вызывается как "функция", которая выполняется не в фоновом режиме. (в отличие от твоего варианта) и никакого лишнего элемента не создается, результат - простая строка - ссылка на память.В чём нет необходимости ? DOM-объект <img> создаётся отдельно для того, чтобы повесить на него обработчик события загрузки картинки "onload", в котором выполняется освобождение памяти, отведённой под объект, созданный методом URL.createObjectURL() . Загрузка картинки начинается асинхронно сразу после присваивания img.src=...

После выполнения вашего изначального кода картинка ещё не загружена (не отрендерина). Чтобы отловить момент, когда она завершит загрузку (рендеринг), и нужен обработчик события "onload". Освобождать память, отведённую под объект, созданный методом URL.createObjectURL() , можно только после завершения загрузки (рендеринга) картинки.

авторпри указании реального uri картинки - происходит загрузка картинки с ссервера.
что происходит при при указании src='blob:http://www.site.ru/17b3ab49-dbc2-48e5-afc2-be1d64cec7ef' не понятноЯ же написал в первых постах, что метод URL.createObjectURL() создаёт в оперативной памяти специальный объект и возвращает на него строковую объектную ссылку специального формата, которую можно присваивать img.src . В этом случае картинка загружается (рендерится) из этого специального объекта, на который указывает эта специальная ссылка. После завершения рендеринга картинки этот специальный объект остаётся в памяти и его нужно (желательно) явно освобождать методом URL.revokeObjectURL() . И освобождать только после того, как завершится рендеринг картинки (событие "onload").

авторможет что-то и изменилось, но никак я не смог этого заметить этого.Зато по фэншую...

автора рендеринг картинок происходит на на событии onload. рендеринг проимходит в момент первого появления картинки на экране. это проявляется в виде задержки , дергании, рывках...Картинка начинает рендериться в момент присваивания img.src = ... (либо создания/добавления узла img с указанным src , как в вашем изначальном коде), завершается рендеринг непосредственно перед генерацией события "onload" (или "onerror" - при ошибках рендеринга).

А " момент первого появления картинки " - это момент после завершения рендеринга этой самой картинки.
Что у вас там тормозит и когда - всецело зависит от логики кода (вы же не одну картинку загружаете и отображаете)