Comments 37
Круто, бро!
А чем Power Query не угодил?) Ну или на край VBA родной?)
Power Query не подходит при нестандартных таблицах. Да и автоматизировать сложно.
VBA - я им плохо владею, он мне не нравится, он медленный, он плохо поддерживает кириллицу и постоянно блокируется Excel-ем.
Power Query не подходит при нестандартных таблицах
Видимо я с такими еще не сталкивался) Счета обрабатываются вроде довольно легко, хоть там и при переводе в Power Query изначально жутко мясо показывает)
Честно скажу не читал статью. Но зацепил заголовок: "навайбкодил", "самый быстрый". Но в статье никаких замеров с аналогами нет. А с чего тогда вывод про самый быстрый? Потому что где то там используется Rust? Если только поэтому то вывод мне кажется поспешным а заголовок кликбейтным.
"[решение на openpyxl] съело всю доступную (из 32 гб) оперативку и 50 гб файла подкачки, и всё равно не справилось. Терпение кончилось быстрее. Потому я и
навайбкодилнаписал своё решение. Новое решение (на компьютере клиента) справилось за 2 минуты с крошечным потреблением ОЗУ "
Но да, надо отдельно провести тесты. Я в основном судил "на глаз", там разница очень заметная.
rust выбрал потому что я его знаю. Чистый python довольно медленный.
Сделал тесты, x24 по скорости. А также (личные замеры) потребление памяти сократилось с 3000 мб до 37 мб. Причём openpyxl ещё таблицу сломал, Excel потребовал восстановления.
UPD: Обновил и саму статью. А вы мне ещё минусов наставили...
Почему редактирование очень медленное и как оно могло сожрать 80гб памяти.
Там же всего и надо распаковать зип архив с xml файлами, внести в них правки и запаковать обратно. Питон не должен был стать узким местом.
// Find the row containing the target cell.
let row_marker = format!("<row r=\"{}\"", row_num);
if let Some(row_start) = self
.sheet_xml
.windows(row_marker.len())
.position(|w| w == row_marker.as_bytes())Это ваша библиотека так с XML работает?
Да (точнее, там quick_xml используется)
Навайбкожено видимо. Потом в куче мест раскопирован шаблон работы, подозрительно напоминающий оной из readme, явно видно, что бездумной нейросетью:
весь файл вычитали в массив, но для чтения использует копирующие методы.
Reader<[u8]>, который создается, может возвращать события, заимствующие данные событий из общего массива. Тем более, что все прочитанные таким образом события сразу выкидываютсяподразумевается UTF-8. Хотя вряд ли будет что-то другое. По хорошему надо пользоваться декодером, который дает
Readerв одном месте
Readerсоздали и настроили, а потом ниже еще раз (а первый не использовался)
редактирование уже имеющихся xlsx файлов это очень медленный процесс, гораздо медленнее чем чтение и запись. Поддержка такого режима есть только у openpyxl, там все операции очень долгие и требуют очень много ресурсов. "Точкой невозврата" стал случай, когда решение на openpyxl работало полчаса, съело всю доступную (из 32 гб) оперативку и 50 гб файла подкачки, и всё равно не справилось.
Простите, что!? Можете точный пример привести, что за операцию вы делали, которая привела к таким последствиям? Подозреваю, что проблема не в Python. Он обрабатывает несколько гигабайтные файлы с миллионами строк в таблицах легко и не напрягаясь.
Может пишет всё на диск после каждой операции?
Будь моя воля, показал бы оригинальный файл, но он конфиденциальный. В ближайшее время попробую создать имитацию с фальшивыми данными.
Openpyxl - очень странная штука, а точнее бесполезная. Судя по моему опыту - зависимость кол-ва оперативки от размера файла - чуть ли не квадратичная. Прочитать файл 1мб - легко, 10 мб - уже не так легко, но в пределах гига оперативки, а на 40мб у меня ушло 8+Гб оперативки. Больше никогда не использовал openpyxl после того случая. Хотя можно на досуге посмотреть, что там в репе происходит, пофиксить
Лучше мой Excelsior (я так назвал либу) улучши!
Reader и Writer для Excel файлов в pandas по умолчанию используют `openpyxl` но при загрузке и записи из pandas никогда с какими-то особыми тормозами или нехваткой оперативы не сталкивался (правда я только за Linux говорю, под win мало использовал). При этом pandas использует Cython и NumPy написанную на С для эффективной работы с данными и трудно поверить, что разработчики pandas стали бы использовать совсем не эффективную библиотеку для работы с Excel файлами. Есть `XlsxWriter`, про который пишут, что он может быть в 4 раза эффективней чем `openpyxl` при записи. У самого `openpyxl` есть оптимизированный режим только на запись. Для win возможно больше подойдёт IronXL для Python поскольку является компонентом .NET.
В общем я совсем не против чтобы для увеличения эффективности сделать библиотеки на высокопроизводительных языках типа C/C++, Go или Rust и использовать их в Python для оптимизации "узких мест", но что-то мне подсказывает, что сабж это не тот случай, а проблема скорее всего была из-за какого-то неправильного использования.
У openpyxl вполне хорошо работает режим записи, но тут речь про дозапись/редактирование уже готовых, а не создание новых файлов. Примерно такое
wirh pd.ExcelWriter(engine="openpyxl", mode="a" )
Почему я начал писать excelsior - именно этот режим, именно в append формате, слишком медленный. Write быстрый, append медленный.
а какие грязные данные и итоговые?
Хорош! И пусть не верят и относятся к вайбкоду плохо, но чатгпт для меня написал уже с десяток разных ботов для телеги и даже пару игр с мультиплеером на html+js
Примеры игр можно? Флепи берд и тетрис можно найти в Гугле по первому запросу, чат жпт тут не нужен.
Дай ссылки на ботов и игры. Не вериться
Слава Богу хоть игры не на flash написал
Тут вайбкодил человек, который знает python и rust. Вайбкодить программистам ниже мидла запрещено, т.к. ни задачу сформулировать не могут, ни результат прочитать.
Помнится давно делал инструменты для обработки .docx и .xlsx, так вот стандартный подход подразумевает парсинг XML в объектную модель, работу с ней, а потом обратную запаковку. Все это жрет неимоверное количество ресурсов.
Тогда попробовал работать с XML как со строкой. Геморойно, костыльно, легко сломать разметку и сложно отлаживать. Но результат того стоит - такой подход и гораздо быстрее и тотально экономичнее по ресурсам.
Здесь похоже нормальный случай, но на всякий случай скажу (вдруг кто не знает): Использование assert'ов в коде не считается хорошим тоном. Например потому что их можно случайно отключить
Навайбкодил самый быстрый xlsx editor