Вопрос по производительности макроса (перенос данных из csv в ods (>100к ячеек))

[Strohmann]

Добрый день, товарищи.

Стоит задача формировать отчёт на основе файла экспорта из WinCC. Данные экспортируются в csv формате, значение параметра снимается каждые 500мс или каждую секунду. Временной интервал от часа до суток. Для начала необходимо привести к одному виду - создать таблицу odt, в которой будут только значения с секундным шагом.

Столкнулся с очень низкой производительностью своего макроса. В создании макросов я новичок, поэтому прошу совета, каким образом можно ускорить обработку, ведь на обработку данных о значении одного параметра за один час уходит целая минута. И это только на удаление полсекундных отсечек. А ведь потом потребуется еще анализ всех этих значений и создание графиков.

Может быть, я изначально выбрал неправильные средства или методы для реализации своей задачи?

В приложении:

Макрос

Small_Trend_RSPP.csv - источник данных по умолчанию, всего 5 значений для каждого параметра
Large_Trend_RSPP.csv - большой источник данных на 7200 значений

Small_Time_Test.csv - маленький источник данных для проверки параметров со смешанным временем архивирования
Large_Time_Test.csv - большой источник данных для проверки параметров со смешанным временем архивирования

' Местоположение источника данных и файла отчёта задаётся в блоке инициализации
sSourceFile = "C:\Test\Small_Trend_RSPP.csv"
sReportFile = "C:\Test\Small_Trend_RSPP.odt"

Немного конкретики:

CPU: Celeron E3300, 2,5 ГГц
RAM: 2ГБ
OS: WinXP SP3

LibreOffice версия: 4.2.4.2
Параметры LO - память:
Использовать для LO - 256 Мб
Памяти на объект - 10 Мб

[Yakov]

AOO 4.0.1 на примере из файла отработал за 6 секунд на CPU Athlon XP 1700+

[Strohmann]

У меня - 1,75 c. Только там по умолчанию задан совсем маленький исходник на 5 значений каждого параметра, для проверки.

Пожалуйста попробуйте в макросе исправить

sSourceFile = "C:\Test\Small_Trend_RSPP.csv"

на

sSourceFile = "C:\Test\Large_Trend_RSPP.csv"

Ну и опционально

sReportFile = "C:\Test\Large_Trend_RSPP.odt"

и расскажите о Вашем результате.

[rami]

"Многа букав ниасилил" (я о приложенных файлах).

' Местоположение источника данных и файла отчёта задаётся в блоке инициализации
sSourceFile = "C:\Test\Small_Trend_RSPP.csv"
sReportFile = "C:\Test\Small_Trend_RSPP.odt"

1) почему формат файла .odt , а не .ods ? вы хотите вычислять в текстовом редакторе?
2) файл Large_Time_Test.csv практически не содержит полезной информации.
3) в макросе всё что написано на русском (пояснения и окна сообщений) кракозябры
Что за первоисточник данных?

[Strohmann]

1) Ошибся при написании. Не замечал, так как при выполнении макроса таблица формируется всё-равно в Calc, а до сохранения дело ни разу не дошло
2) Что Вас смутило в данном файле? Метки времени - есть, значение параметра - есть. Ну а то, что 99,9% значений - "0" - бывает и такое, в данном случае - это не принципиально.
3) Кракозябры вполне могут быть, уже доводилось безуспешно бороться с кодировкой. Прилагаю odt-файл. Первоисточник - экспорт через компонент "OnlineTrendControl" WinCC 7.0,

[Yakov]

3) в макросе всё что написано на русском (пояснения и окна сообщений) кракозябры

Это кодировка Win1251, в блокноте WinXP открылось нормально

[Yakov]

и расскажите о Вашем результате.

Существенно дольше,
из этого только загрузка csv занимает 15 секунд, а потом работает макрос...очень долго

[Strohmann]

В том-то и беда. 22 минуты у меня уходило на обработку Large_Trend_RSPP.csv.

Проблема в том, как я написал макрос или это действительно столь небыстрый процесс?

Фактически макрос реализует следующую задачу - прореживает значения параметров, снимающихся раз в 500мс, пропуская одно значение. Я копирую в отчёт только одно из значений имеющие одинаковую метку времени (Например "5/26/2014 8:00:09 AM" и "5/26/2014 8:00:09 AM" фактически сняты в "5/26/2014 8:00:08:500 AM" и "5/26/2014 8:00:09 AM", но инженеры SIEMENS почему-то решили, что об этом нам знать не стоит). В дальнейшем там должна быть еще куча работы, но у меня уже опустились руки, глядя на время исполнения.

[rami]

Я уже 15 минут рву волосы на голове, а обработка файла ещё не закончилась
Этот макрос такой тормоз, он по две ячейки за раз обрабатывает. Надо обрабатывать диапазонами.
Если доживу до окончания работы макроса  , может быть помогу. Я думаю, что оптимальное время обработки такого объёма данных должно быть несколько секунд. Уже больше 25 минут прошло, а конца не видно. Это не нормально.

[Strohmann]

Я не вижу другого способа вычленения дублей (значений одного параметра с одинаковой меткой времени), чем такой вот перебор - если подскажете, как свести задачу к копированию диапазонов - буду безмерно рад.

Просто беда в том, что параметр в колонке B (условно) может иметь время опроса 500мс и, соответственно, значений будет в 2 раза больше, чем у параметра в колонке D (условно), время опроса которого 1 секунда. И тупо удалить ряд i+1, имеющий одинаковую метку времени с рядом i нельзя, так как в колонке D у нас совсем другая метка времени. Это хорошо видно в примере "Small_Time_Test.csv" или "Large_Time_Test.csv"

[rami]

Уже 50 минут обрабатывается файл, думаю, что через 10 — 20 минут закончится (я оптимист). Не хочу прерывать макрос, т.к. нужен конечный результат для сравнения с тем, что я могу сделать.

[Strohmann]

Оценить оставшееся время можно посмотрев, какие колонки в данный момент заполнены и сравнив с исходником. AR или AV является последней колонкой, в зависимости от исходника.

А для оценки конечного результата как раз и приложены исходники с префиксом Small =)

[rami]

Обрабатывалось больше чем полтора часа, думаю, что можно сделать

[VlhOwn]

Откройте свой csv-файл в любой БД (copy table from csv), отберите запросом записи с уникальным значением временнОй отметки (select distinct) и запшите результат запроса в csv-файл (copy table to csv) - будет всяко быстрее вашего макроса.

[rami]

Пробовал разные варианты, например
1) удаление лишних ячеек вместо копирования, не ускоряет
2) замена формата с csv на ods уменьшает вес файла в 7 раз, но не ускоряет
3) если оставить только две колонки на листе, работает быстрее, но не существенно
А что делаете дальше с данными? Графики, статистика?