Минутка ненависти

Да есть полно задач, где файлы заведомо небольшого размера, высасывай-не высасывай.

Конечно есть. А еще есть хотя-бы fsize и контроль возвращаемого malloc значения.

Питон, но не суть

Вообще-то суть. Вся нормальная скриптота имеет ограничение на размер кучи. Поэтому с одной стороны там народ в курсе, что память не бесконечная, а с другой достаточно безопасно читать всё в память если предполагается что файлы маленькие.

Где какой объект и так известно, собирать ничего не надо. Всё смещения лежат в /Catalog в конце файла (начале для линеаризованных). И вообще говоря самое простое и быстрое - просто писать в конец и потом переписать каталог. Можно вообще делать append update и писать совсем в конец файла не трогая оригинал, у апдейта свой микрокаталог.

Но есть определённые требования/действия из-за которых приходится перезаписывать весь файл объект за объектом (например та же линеаризация), и в этом случае начинается жопа потому что pdf это по сути сильно вложенный xml только вместо вложенности в 90% случаев ссылки в рандомные точки файла. И если пытаешься их резолвить и писать не затягивая все содержимое в память - начинаешь бегать взад-вперед читая с диска мелкие куски по 100 байт, что на крупных файлах создаёт приличные (с точки зрения синхронного вебсервиса) тормоза. Юзер ж не хочет ждать 10-15 секунд на спиннере, он хочет чтоб раз и все готово.

Ипотека мне теперь не светит. Раньше было 1-1.5%, теперь 4-5% ввиду определённых событий которых хз каким боком трогают Швейцарию. Сколько это в месяц в условиях стоимости квартиры минимум 1кк нерублей можешь прикинуть сам, но если кратко - я столько не вывезу, жить тоже хочется всё-таки.

канонiчный ответ

И десятиричное пишется перед гласными. Хотите пользоваться классическим правописаніемъ, так пишите лучше так: каноничный ответъ.

Грамотей-опричник в треде, все в телегу!

Закидать ятями! Ѣ

помню Kate/Kwrite как и gVim не читали «тупо в RAM», а Okteta/GHex звучит как что-то хэкирское

это должно быть закрыто спец флагом

Не нужно никаких спецфлагов, нужно автоматизировать проверку нефункциональных требований. Если человек может что-то не сделать (читай проверить входной объем), то он когда-нибудь это не сделает. И флажки тут половинчатое решение. Нужно явно отобрать у него возможность косячить. Превышено потребление памяти/процессора для заданных данных - получай алерт на почту, несколько раз придет - научится модульные тесты под это писать)

Еще никто не сказал mmap()? И буфер, и читается по требованию, и освобождается частями при необходимости.

Для рандомного чтения - те же яйца, оно хорошо для последовательного.

для «этого» итераторы

то что массовую безграмотность можно преодолевать выбраковывающим(на премию дарвина) при безграмотном применении инструментом не вполне экономически оправданно в современной мир-системе

а вообще каменный век в софтостроении завершится не из за дефицита «камней»

Компьютерная революция ещё не случилась((с)- чей-то)

Такие дела

tl;dr file.read() = расстрел

Тебя =) Ведь это ты обязан перед чтением сделать if max_size > file.tell(): узнав его размер и только потом считать его, если не уверен в границах размера нужного файла =)

Ааааааааа, апять меня некропостеры подставили. Подставная подстава!

В кложе функции, читающие и пишущие файл целиком, называются slurp и spit. Ну тут как бы по самим названиям всё должно быть понятно.

tl;dr file.read() = расстрел

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

Питон, но не суть

А ты ожидал от питона чего-то другого?

кое-кто умный опять решил что память нынче дешёвая и парсер много не съест

Ну щас именно так можно код писать, привыкай.

Систему нужно тестировать на экстремальные условия, чтобы понять, где у неё границы.

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

Пример: в написанном мной сервере, который я делал года три назад, есть модуль работы с сырыми TCP-данными, которые он получает, обрабатывает и схороняет в хранилище для дальнейшей обработки. Проверки и прочее, конечно же, есть. В потоке передается серийный номер устройства, который проверяется на наличие в БД: данные пишутся только если устройство зарегистрировано в системе. При регистрации новых устройств у юзера порезано все, кроме возможности ввести шестизначный серийник в нужное поле, затем это проверяется на валидность, на наличие в бд… Доступа к серверу у юзера тоже, соотвественно нет.

Тестировал все: норм работает.

Сервер отработал год, просят посмотреть – че-то все упало. Долго смотрел в логи… Пока не обнаружил, что там есть задвоение серинийка в БД, чего быть просто не может и не должно. Владелец говорит, что да, добавлял новые. На риторический вопрос «Как ты, демон, это сделал?» он ответить не смог :)

Реальная жопа что когда говоришь людям проверить блин потребление памяти, в ответ слышишь «купи больше оперативки».

Ну дык щас так модно. Телефон менять каждый год, потому что говноид уже не вывозит на 10 гигах рамы, и так далее.

А потом основной stakeholder захочет засунуть туда 5 метров вместо 2, обломится, набутылит ПМа, и ПМ побежит к тебе с криками «срочно».

плюс много

Ну так что ты хочешь о разработки класса «велики фу, костыли фу, давай вон ту модную либу сюда»

Перекатывайся в микросервисы. Зачем тебе по хреновому smtp клиенту на каждое окружение, пусть будет 2 штуки и хватит.

Наркоман. Из-за тебя все опять обнекропосились.

Да блин, читаю тред, что-то комменты знакомые.

Ты тоже попался в коварную лавушку. Бежим отседова скорееее

Дядя тру-линуксоид, открой в линуксовом текстовом редакторе текстовый файл в 5 ГБ. И спросите себя, почему редакторы 80х умели открывать файлы объемом больше оперативки.

Так поинтересуйся у разработчика, чем обоснован такой код. Потом напиши, что он ответил. Всё просто же, нет?

Спрос на фичу «открывать файлы объемом больше оперативки» был больше, ввиду дефицита оперативки. А сейчас спрос на свистоперделки.

Ну вот маки вышли. PRO серии. С 8 ГБ RAM. 8 ГБ, КАРЛ!

gimp легко умеет открывать несколько файлов совокупным объёмом больше оперативки. У него на уровне приложения своп.

Умеет ли он открывать один файл, который размером больше оперативки, я не проверял.)

lilyterm умеет работать в режиме бесконечной истории терминала (пока не закончится место на файловой системе).

А почему ограничение «unique» на колонку не добавили, когда схему БД составляли?

Ну, как говорится, хорошая мысля приходит опосля.

ну это ж базовая аксиома, а не «хорошая мысля».

У меня все, продолжаю наблюдение

А как тебе такое, Дэвид Блейн.

The letter Q in Firefox stands for Quality

Если написал я - то да, меня. В общем случае - того кто написал без проверки размера

Если нужен файл целиком - да. Но это не должно быть дефолтным поведением поскольку оно потенциально опасно. Это как у какого-нибудь thread pool executor’а - по умолчанию ждать все таски на shutdown. Можно не ждать, но это опасно и на это отдельный флаг.

Модные либы это да. Один раз видел либу, которая «красиво форматировала dict для консоли». Это шняга тянула за собой пандас (крайне жирная либа для ml и статистики, если ты не встречал) и все от чего он зависит

Да всех наверное либо так делали, либо так делают, либо так будут делать, есть нюансы когда это вполне нормально с некоторыми но, но лень расписывать =)

А так, можно рассматривать это как уязвимость на отказ. Подсунуть безобидной программке конфиг размером в пару размеров памяти и увести систему в жёсткий swap тормоз. Но эт такое себе. Но ограничивать размеры конфига каким бы то ни было лимитом тоже такое себе. Конечно универсальным вариантом будет для всех чтение в буфер размером N обработка и по кругу, ноооо не всегда это адекватно, у пользователя может быть мало памяти, но огромный и сверхбыстрый swap, будет странно что если я выясню в своём ПО что оперативки тупо не хватить загрузить файл и выдам ошибку. По хорошему программе просто должно быть настрать модет там у тебя мегабайт оперативки, а может терабайт, ЭВМ либо справится с задачей, либо нет. Но, всё же если есть возможность и предположения о том что файл большой то обрабатывать его фиксированными блоками, если алгоритмически это возможно без обращения к уже обработанным частям файла. Ну тут не всё короче так однозначно. Если надо читать файл всегда целиком так как он нужен весь, то выбора нет (почти)

Почему по дефолту? Там и так есть возможность задать размер сколько прочитать, или ты хочешь отдельный флаг, типа full=True? или встроить проверку размера файла по умолчанию, чтобы потом их все время выключать? Где-то в других языках это вообще есть?

Просто понятно, что разработчик не учел возможность загрузки больших файлов, и это похоже на баг. Но говорить что язык или что read дерьмовый, это как-то странно, по крайней мере имхо это не та причина.

Там и так есть возможность задать размер сколько прочитать, или ты хочешь отдельный флаг, типа full=True

Да, именно. Чтоб дефолт был не -1, а условно 1000 символов, или 1млн символов. Но в любом случае что-то ограниченное логикой, а не оперативной памятью. Если человек хочет -1 - пожалуйста, но это не должно быть стандартным поведением

Конечно универсальным вариантом будет для всех чтение в буфер размером N обработка и по кругу

Универсальным вариантом будет открыто спросить разработчика сколько читать. Если сказал «всё» - ссзб

Подсунуть безобидной программке конфиг размером в пару размеров памяти и увести систему в жёсткий swap тормоз

Понимаешь какая штука, дело не в самом read, а в том что за ним следует. У тебя иммутабельная строка. Разраб делает read, получает Х в памяти, потом чистит символы регуляркой - получает 2Х, потом конвертирует в b64 - получает 3.3Х. И я если что описываю стандартную работу штатного email.Message пистона

Кратко - разрешая по дефолту read на все разом, мы по дефолту разрешаем операции над всем этим в памяти не используя стриминг. И вот это уже больно.

Обоже, зачем им пандас. Сплит строки какой-нибудь им делали поди.