#c# #.net #excel #nuget #closedxml
#c# #.net #excel #nuget #closedxml
Вопрос:
Мне нужно сохранить данные в файл Excel (.xlsx). Я решил использовать NuGet «ClosedXML» (v0.95.3) (https://www.nuget.org/packages/ClosedXML /) для его реализации, после получения нескольких рекомендаций по этому NuGet от разных разработчиков.
Недавно я столкнулся с проблемой при экспорте 50 тыс. строк:
- Сам процесс сохранения (после того, как все данные уже были добавлены в файл) занимает очень много времени, около ~ 10 секунд
- Это без упоминания о том, что оформление этих строк: шрифт, границы, настройка ширины столбцов и т.д. Занимает Около ~ 12 секунд.
- Это без упоминания того факта, что для извлечения и записи данных в файл мне требуется около ~ 20, поэтому весь процесс в таком случае занимает у меня ~ 45 секунд (слишком много времени !!).
Я сохраняю данные в заданный поток, используя метод «SaveAs ()», и я уже использовал «XLEventTracking.Отключена» оптимизация.
Вероятно, я не первый, кто имеет дело с файлами Excel, поэтому:
- Кто-нибудь из вас знаком с NuGet «ClosedXML» и сталкивался с такой проблемой в прошлом?
- Вы используете другой NuGet для файлов Excel? (даже если это стоит денег).
Заранее спасибо!
Комментарии:
1. Файл xlsx — это просто сжатый XML. Вы можете создать двухстрочный лист Excel, распаковать его, посмотреть xml и просто сгенерировать текстовый файл с 50 000 строками и сжать его.
2. ClosedXML сохраняет модель всех ячеек в памяти и записывает ее в файл только при сохранении. Преимущество в том, что это позволяет использовать очень полезный API для работы с вашей электронной таблицей, но недостатком является объем памяти. Если вы просто хотите сбросить данные в файл, я бы посмотрел на другие инструменты, которые записывают в файл. (Я сопровождающий ClosedXML).
Ответ №1:
Я использовал ClosedXML в течение нескольких лет, и я должен признать, что библиотека — начиная с версии 0.95.1 — практически непригодна для больших отчетов Excel. Использование памяти / занимаемый объем — это катастрофа. Действительно большой отчет может легко выделить несколько гигабайт оперативной памяти.
Проблемы с производительностью, которые вы видели, связаны с GC (сборкой мусора). Глядя на код, вы быстро понимаете, что для исправления этого потребуется несколько итераций улучшений.
Я бы рекомендовал посмотреть другие библиотеки. Лично я предпочитаю использовать собственную библиотеку libxlsxwriter. Вы можете легко интегрироваться с ним, используя DllImport interop. Для больших отчетов рассмотрите режим постоянной памяти. При постоянной памяти он превосходит ClosedXML как по ЦП, так и по ОЗУ.
Комментарии:
1. Сопровождающий ClosedXML здесь. Я действительно удивлен, что вы говорите, что использование памяти регрессировало. Мы работали над этим, и около 0,93 произошло значительное улучшение. Если у вас есть конкретный вариант использования, в котором он регрессировал в версии 0.95.1, пожалуйста, зарегистрируйте его в репозитории.
2. Конечно, 0.95.1 был улучшением во многих отношениях. Но этого недостаточно. Просто создайте лист со 100 столбцами и более 100 000 строк. В моих тестах мы легко достигли уровня использования оперативной памяти 6 ГБ. С
libxlsxwriterмы сохранили использование оперативной памяти на уровне 20 МБ или около того.3. У меня такая же проблема с 0.96. Создание электронной таблицы с примерно 100 тысячами строк по понятным причинам занимает значительное время, но именно вызов SaveAs является настоящим убийцей и занимает большую часть времени и системных ресурсов.