Не знаю, сам сижу на рокете, очень доволен. По поводу Тинькова тоже очень много нехорошего ходит, с другой стороны, но если устраивает все, то и спорить нечего, полагаю.
Ошибочное мнение – считать мнение другого человека ошибочным. Я понимаю, есть такие случаи, когда ошибочность действительно очевидна, но здесь не так. К тому же, как ни крути, в среднем jQuery выполняет все действия медленнее в два раза, и пора бы уже в 2017 году отказаться от бессмысленной на данный момент библиотеки.
Я повторял этот опыт, и при размере сгенерированного файла в 150мб нода ела под 800 мб памяти и сборка мусора не произошла ни разу. При этом процесс выполнения стал крайне медленным, по одной инерации в секунду примерно, так что особого смысла продолжать не было. Даже если часть памяти бы всё-таки освобождалась сразу, всё равно это не отменяет несостоятельность использования такого метода для получения данных по кускам и склейки их. Тем более, сейчас в ноде Array.join работает не медленнее конкатенации.
Да, это действительно так работает, хоть мне и не совсем понятна эта логика. Мне кажется, логичнее было бы очищать наименее используемые строки из пула при достижении определённого размера оперативной памяти. В общем, эта вещь отлично помогает при частой конкатенации одних и тех же строк, что используется в разработке на js часто, но собирать большие объемы данных по кусочкам с помощью неё не стоит.
Спасибо, понял. Не знаю, почему в моём случае не было такого, нужно будет изучить этот вопрос. Спасибо, о конкатенации строк и памяти вообще нигде ничего нет.
Сделал вот сейчас же функцию, которая огромное количество раз конкатенирует Math.random() в переменную, чтобы исключить любую возможность кэширования, а потом конкатенирует эту переменную к исходной, одновременно с этим показывал размер в килобайтах строки. На строке в ~134 мбайта нода ела 138 мбайт.
Я вот прямо сейчас написал ради интереса такую штуку:
const teststring = "" //здесь было 512 utf-8 символов.
let string = "";
let multiplier = "2";
setInterval(() => {
if(string.length < 1024*1024*2) {
string += teststring;
console.log('1'); // для отслеживания
}
}, 10)
Следил встроенным в хром диспетчером задач за потреблением памяти и потреблением памяти javascript. Скрипт сделал всё верно, досчитал до 4096. За это время общая потребляемая память выросла, но даже не на 2 мегабайта. Было видно, как сборщик памяти раз в несколько секунд очищал память на 100-200кб.
В этом и суть. Мне кажется, нужно стараться использовать своё и как можно меньше библиотек, если занимаешься серьёзными проектами. Если фрилансить, или поджимает время – для этого есть библиотеки.
Да, отличный вопрос. Дело в том, что это всё, несомненно, важные вещи, но цель была немного другая — собрать базовый функционал, который бы вменяемо работал. Другие важные вещи, вроде поддержки кодировок, длины запросов, да даже нормального определения mime-типов, это всё материал для следующих статей.
Я много раз говорил и повторю ещё раз, что эта статья не призывала и не призывает кого-либо использовать подобное решение на постоянной основе. Это сервер, который я начал писать исключительно для себя, и пока что в нём нет многих важных функций, например. Пока что этот сервер – скорее игрушка для тех, кто хочет сделать что-либо подобное на досуге. Тем не менее, спасибо за комментарии!
Следил встроенным в хром диспетчером задач за потреблением памяти и потреблением памяти javascript. Скрипт сделал всё верно, досчитал до 4096. За это время общая потребляемая память выросла, но даже не на 2 мегабайта. Было видно, как сборщик памяти раз в несколько секунд очищал память на 100-200кб.