Письма с превышением уплаты за год

[lubezniy]

Вообще же я вижу только один путь для дальнейшего ускорения алгоритмов работы с наименьшей головной болью - это использование реляционной шустрой СУБД вроде Firebird Embedded или SQLite с индексируемыми таблицами. Но этот подход, сильно упрощая работу программисту, создаёт проблемы админу и особенно не слишком опытному простому пользователю, если ему нужно обновить версию или заставить программу работать на конкретном компьютере в случае возникновения каких-либо глюков. Сейчас программа состоит фактически из одного исполняемого файла, не использующего внешние и отдельные особо глючные компоненты вроде Microsoft XML Parser (я использую парсер собственного производства), а практически вся работа делается в оперативной памяти. При таком раскладе нет никаких проблем с правами доступа к файлам, несовпадением версий компонентов и прочими вопросами работы и обновления. А последствия создания "кружка кройки и шитья" из множества файлов и внешних компонентов, увы, хорошо видны в CheckУфа и в чём-то в CheckXML по пользовательским вопросам. Есть ещё путь создания собственных индексов в программе. Над этим буду думать, но с моими "знаниями" теории программирования, алгоритмов сортировки, поиска и индексирования это не быстрый процесс.

[lubezniy]

Так у Вас же есть набор из 151 файла. А если из них выбрать часть?

Вариант - не подумал как-то об этом. Посмотрим. По идее, должно быть быстрее, и даже не на порядок.

[Михаил Иванович]

Уважаемый Виктор! Мне кажется, что некоторые форумчане хотят от Вас слишком многого. Даже последний вариант вполне удовлетворяет пользователя, не очень "продвинутого" в пользовании различными приложениями. А вот компактная форма протокола в EXCEL вообще очень удобна и понятна бухгалтеру для работы. Сегодня в одной организации формировали отчёт по 2 кварталу, предварительно проверив сальдо на конец 1 квартала. И обнаружили у двух ЗЛ, уволенных в 1 квартале, переплату, а данные уже загружены в базу. Инспектор "прошляпила", не проверила данные даже программой "Переплата и уволенные". Поэтому мы по протоколу уточнили сальдо по всем ЗЛ на начало 2 квартала, после этого начали формирование отчёта.

[vk65]

Вообще же я вижу только один путь для дальнейшего ускорения алгоритмов работы с наименьшей головной болью - это использование реляционной шустрой СУБД вроде Firebird Embedded или SQLite с индексируемыми таблицами.

У меня тоже появлялась мысль предложить Вам посмотреть в сторону SQL. Но, по большому счёту, цель определяет выбор средств. Думаю, по скорости текущий вариант будет устраивать до 95% пользователей. А остальные 5%, как мне кажется, способны самостоятельно разработать средства контроля.

[lubezniy]

У меня тоже появлялась мысль предложить Вам посмотреть в сторону SQL. Но, по большому счёту, цель определяет выбор средств. Думаю, по скорости текущий вариант будет устраивать до 95% пользователей. А остальные 5%, как мне кажется, способны самостоятельно разработать средства контроля.

Я сегодня провёл хронометраж разных этапов работы программы, показавший, что самым медленным является именно чтение файлов: на полном объёме тех самых тестовых данных оно занимает больше часа, а в ходе работы повторяется дважды. Вся остальная работа занимает от силы 10 минут. Ввиду этого перевод на SQL не даст сколь-нибудь ощутимого роста производительности. Посему планирую к следующей версии обратно перейти на однократное чтение всех файлов с их хранением в ОЗУ в виде обычных структур (без XML-тэгов, переводов строк и прочих атрибутов) и тем самым сэкономить минут 40-50 времени на обработку. Увеличение расхода ОЗУ в таком раскладе составит порядка 70-90 МБайт на 12000 застрахованных лиц (текущий расход - порядка 140 МБайт максимум), что при системных требованиях в 512 МБайт в целом является допустимым.

[vk65]

Я сегодня провёл хронометраж разных этапов работы программы, показавший, что самым медленным является именно чтение файлов: на полном объёме тех самых тестовых данных оно занимает больше часа, а в ходе работы повторяется дважды.

Само чтение файлов я Вам переписал, попробуйте. Стало читаться пошустрее. Но и дальнейшая обработка тоже зависит от размеров, я попробовал прогнать 100, 200 и 500 записей, разница во времени ощущается.

[lubezniy]

Само чтение файлов я Вам переписал, попробуйте. Стало читаться пошустрее. Но и дальнейшая обработка тоже зависит от размеров, я попробовал прогнать 100, 200 и 500 записей, разница во времени ощущается.

Спасибо, попробую. Пока привожу результаты хронометража на старом варианте без времени формирования протокола (общее время сегодня составило 2 часа 11 минут):

Время начала обработки - 10:02:00
Список файлов составлен в 11:07:47, времени потрачено 1:05:47 (тут читаются все файлы, отсеиваются файлы без ИС и СПВ-1, составляются список файлов с краткой информацией о них и список отчётных периодов)
Сортировка списка файлов закончена в 11:07:47, времени потрачено 0:00:00 (список файлов сортируется по порядку, в котором он будет обрабатываться - сперва исходные сведения первого отчётного периода из имеющихся в наличии, потом корректирующие и отменяющие сведения этого же периода, далее в том же порядке второй отчётный период и т. д.)
Список сотрудников считан из файлов в 12:13:14, времени потрачено 1:05:27 (тут файлы читаются повторно в ранее определённом порядке, формируется массив данных о сотрудниках с периодами стажа, начислениями и уплатами, с указанием номеров файлов, откуда взяты данные)
Список сотрудников отсортирован в 12:13:26, времени потрачено 0:00:12 (сортировка списка сотрудников по алфавиту)
Список отчётных периодов отсортирован в 12:13:26, времени потрачено 0:00:00 (периоды сортируются для удобства вывода данных в протокол)

[vk65]

Спасибо, попробую. Пока привожу результаты хронометража на старом варианте без времени формирования протокола (общее время сегодня составило 2 часа 11 минут):

Я так понимаю, что больше всего времени занимает парсинг.
Провел я еще один эксперимент. Два набора файлов. Первый - 10 файлов по 50 чел в каждом, второй - 1 файл на 500 чел.
Время обработки: 1 набор - 0:01:04, 2 набор - 0:07:16.
Собственно, я этого и ожидал. Выводы очевидны.

[Валерий Ж]

у меня проверка файлов на 2500 ЗЛ с периодами проверки с 01.01.2010 по 2 кв. 2011г. (итого примерно 10000 ЗЛ) прошла за 30-45 мин., точнее не могу, т.к. отвлекали, Комп 2 гига 2 ядра, при этом вырубил все проги и отдал приоритет Чеку(в смысле уплате переплате) самый высокий. Вот так вот, на мелкие файлы проверяет быстро, и главное понятно.

[lubezniy]

Я так понимаю, что больше всего времени занимает парсинг.
Провел я еще один эксперимент. Два набора файлов. Первый - 10 файлов по 50 чел в каждом, второй - 1 файл на 500 чел.
Время обработки: 1 набор - 0:01:04, 2 набор - 0:07:16.
Собственно, я этого и ожидал. Выводы очевидны.

Ну да. Поэтому я всё же убрал дублирование чтения файлов, поменял алгоритм чтения на предложенный Вами в несколько изменённом виде (Delphi 2009, работая с Unicode-строками и символами по умолчанию, кривовато воспринимает изначальный вариант буфера из Char, расчёт размера файла не нужен, да и буфер можно увеличить) и получил на выходе следующее:
Время начала обработки - 2:27:23
Список файлов составлен в 3:34:11, времени потрачено 1:06:48
Сортировка списка файлов закончена в 3:34:11, времени потрачено 0:00:00
Список сотрудников считан из файлов в 3:34:20, времени потрачено 0:00:09
Список сотрудников отсортирован в 3:34:30, времени потрачено 0:00:10
Список отчётных периодов отсортирован в 3:34:30, времени потрачено 0:00:00
В общем, уменьшение времени обработки оказалось практически двукратным при не слишком значительном увеличении расхода оперативной памяти. Но, прежде чем готовить и выкладывать новую версию, я хочу сравнить протоколы из обоих алгоритмов на предмет разночтений (сейчас повторно получаю текущей версией протокол, который не додумался сохранить), плюс добавить немножко изменений из плана, на которые времени хватит.

[vk65]

Ну да. Поэтому я всё же убрал дублирование чтения файлов, поменял алгоритм чтения на предложенный Вами в несколько изменённом виде (Delphi 2009, работая с Unicode-строками и символами по умолчанию, кривовато воспринимает изначальный вариант буфера из Char, расчёт размера файла не нужен, да и буфер можно увеличить)

Я делал на Delphi 7, проблем не было. На 2009 не пробовал.

В общем, уменьшение времени обработки оказалось практически двукратным при не слишком значительном увеличении расхода оперативной памяти. Но, прежде чем готовить и выкладывать новую версию, я хочу сравнить протоколы из обоих алгоритмов на предмет разночтений (сейчас повторно получаю текущей версией протокол, который не додумался сохранить), плюс добавить немножко изменений из плана, на которые времени хватит.

Вы читаете каждый файл целиком в строку, затем делаете его разборку.
Мне кажется, если читать блоками по 30-60к и обрабатывать "на лету", скорость увеличится в разы.
И ещё, очень не хватает прогресс-бара, особенно для больших объёмов данных.

[lubezniy]

Я делал на Delphi 7, проблем не было. На 2009 не пробовал.

На 7 и не должно быть проблем. А у меня программа вылетала по Access Violation.

Вы читаете каждый файл целиком в строку, затем делаете его разборку. Мне кажется, если читать блоками по 30-60к и обрабатывать "на лету", скорость увеличится в разы.

Возможно. Во всяком случае, по такому принципу построен и XML-парсер от Microsoft, и ещё один парсер, который я ограниченно использовал в других программах из-за того, что он не поддерживал русские кодировки. Но я пока не готов менять принцип построения своего XML-парсера.

И ещё, очень не хватает прогресс-бара, особенно для больших объёмов данных.

С этим полностью согласен. Сейчас делаю.

[vk65]

На 7 и не должно быть проблем. А у меня программа вылетала по Access Violation.

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

Возможно. Во всяком случае, по такому принципу построен и XML-парсер от Microsoft, и ещё один парсер, который я ограниченно использовал в других программах из-за того, что он не поддерживал русские кодировки. Но я пока не готов менять принцип построения своего XML-парсера.

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

[lubezniy]

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

Не получится, если только не хочется ещё больше замедлить процесс (по сравнению с тем, что я ещё не выложил). Мой парсер (весь целиком прописан в xmlwork.pas) обрабатывает тэги не по очереди, как другие, а рекурсивно, начиная с корневого тэга (т. е., ФайлПФР) и заканчивая последним child-ом. На выходе выдаётся полный массив тэгов с атрибутами, вложенными тэгами и их содержимым. Поэтому обрабатывается сразу весь файл. И именно этот этап, на мой взгляд, занимает больше всего времени: формирование структуры TSZV6File - это уже цветочки. Для смены расклада нужно переписывать почти всю логику программы и фактически заново её отлаживать.

[vk65]

Не получится, если только не хочется ещё больше замедлить процесс

Виктор, Вы меня видимо не поняли. Допустим, есть реальная организация с 1000 ЗЛ. Можно всех работников выгрузить в 1 файл. А можно в 50 файлов по 20 чел. И второй вариант Вашей программой будет обработан значительно быстрее, так как основное замедление происходит при парсинге строки Data.