Answer в коллбеке хранит данные, но за пределами fs.readFileSync, answer

= "", как мне сделать так, чтобы данные добавлялись в answer, то есть не выводило пустую строку в конце кода?

readFileSync синхронный без колбэка Либо поменяйте на readFile

let answer = filesName.reduce(async (answer, filename) => answer + await fs.promises.readFile(PATH_TO_MESSAGE + filename), '')

спасибо, тупанул

бред

В чём?

оно работает

у тебя в reduce передаётся асинхронная функция

И что?

В reduce параметр answer это promise

>sync >использует колбек кто-то явно не пользуется тайпингами которые вскод поставляет по дефолту

А разве это vscode? Это похоже на https://carbon.now.sh

ну ты думаешь он код писал в карбоне а не в редакторе?

Может в виме или блокноте ) зачем гадать если можно спросить топикстартера

(async () => { const fs = require('fs') const files = ['/etc/lsb-release', '/etc/passwd'] const sha1 = require('sha1') let answer = (await Promise.all(files.map(async filename => filename + ' ' + sha1(await fs.promises.readFile(filename))))).join('\n') console.log(answer) })()

а в одну строчку слабо?

Нет препятствий патриотам

Если это тоже троллинг, то не стоит, а то кто-нибудь ещё не поймет и действительно начнёт работать с fs через promise.all

Ну и что такого?

Попробуй протестировать операции с несколькими десятками файлов нормального размера (пару мегабайт хотя бы, но чем больше размер, тем показательнее должны быть результаты) с помощью fs через promise.all и через for с await в цикле Ну или поищи по чату, уже обсуждали и сравнивали

Ну в таком случае надо поток хешировать, а не читать в память вообще

не понял мысль, если честно для хэширования тоже нужно читать в память, но при чём здесь оно? я писал о том, что с файлами лучше работать последовательно, а не "кусочек от одного, кусочек от другого", как это будет при promise.all

Хешировать поблочно, а не целиком ;)

С чего это лучше?

А ты знаешь толк в извращениях

Это не извращение, а нормальный код

Не соглашусь. Это из серии научи плохому

md5sum World_of_Roguecraft_Episode1_XviD.avi b68c1589e2735e784af01a2d30648a36 World_of_Roguecraft_Episode1_XviD.avi

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

тема походу холиварная, но эффективней работать с io параллельно, а не последовательно

здесь нет холивара, это легко проверяется тестами

моя практика говорит о том, что параллельно - эффективней

ну давай конкретную задачу определим если тебе надо скопировать пять десятков файлов объёмом минимум в полтора мегабайта (фотки) - ты будешь их копировать через promise.all? оговариваем, что копировать почему-то надо нодой, а не иначе

да, именно так и буду

Копирование и чтение это разные вещи

я написал тест и проверил на примерно сотне файлов разного размера на ssd - действительно, я ошибался ожидая большой просадки даже при копировании через pipe всё ок: у меня результаты плавают, то одно быстрее, то другое, но в любом случае promise.all в среднем не хуже последовательного копирования gist.github.com/6n8bdhkocirh/0be5e53dc9bb9eabab648c8dafbd7dbb к сожалению, у меня сейчас нет возможности запустить тест на hdd, но я ожидаю (на основе своего опыта), что на hdd разница будет заметной, и не в пользу promise.all, поэтому пока что по-прежнему считаю, что не стоит его использовать при работе с fs

А че это вы фейк профиль сделали?))

случайно так вышло (первый тест с рабочего ноута писал, не мог на нём зайти под своим аккаунтом)

общий размер данных какой был?

Общий размер не мерял. Под сотню файлов, больших (500 мб) штук пять, десяток маленьких, остальные в несколько десятков мб

а за какое время один тест проходил?

Не помню, если принципиально могу завтра посмотреть Больше двух секунд на один вариант копирования А у тебя какие результаты в сравнении?

я не запускал, мне лениво