Н-да? Либо мы играем в слова с постановкой задачи (если "слить результат в /dev/null" считается корректным, то пустая программа даёт тот же самый ответ), либо мы во время компиляции пре-генерим эту семигигабайтную выходную строку (никаких проблем, в современных языках это делается дописыванием одного ключевого слова, const или аналогичного в зависимости от языка). Но я подозреваю уверен, что получившийся монстр будет зачитываться в память дольше.
Собственно, даже если и бинарник, и результаты будут изначально в памяти (на ram-диске), то всё равно тупое копирование длинной строки байтов -- не самый быстрый способ получить выходную строку. Оптимизированные "на скорость" (а не "на объём") алгоритмы сжатия (ну то есть, разжатия) заполняют её быстрее, за счёт меньшего количества чтений из памяти исходной строки (собственно алгоритм оказывается дешевле). А результат fizzbuzz, очевидно, хорошо сжимается.
Кому тут ещё санитары нужны?
... Press any key... No, no, no, NOT THAT ONE! ...
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2021-04-06 01:05 pm (UTC)подозреваюуверен, что получившийся монстр будет зачитываться в память дольше.Собственно, даже если и бинарник, и результаты будут изначально в памяти (на ram-диске), то всё равно тупое копирование длинной строки байтов -- не самый быстрый способ получить выходную строку. Оптимизированные "на скорость" (а не "на объём") алгоритмы сжатия (ну то есть, разжатия) заполняют её быстрее, за счёт меньшего количества чтений из памяти исходной строки (собственно алгоритм оказывается дешевле). А результат fizzbuzz, очевидно, хорошо сжимается.
Кому тут ещё санитары нужны?
... Press any key... No, no, no, NOT THAT ONE! ...