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

[vk65]

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

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

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

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

[lubezniy]

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

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

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

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

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

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

[vk65]

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

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

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

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

[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
В общем, уменьшение времени обработки оказалось практически двукратным при не слишком значительном увеличении расхода оперативной памяти. Но, прежде чем готовить и выкладывать новую версию, я хочу сравнить протоколы из обоих алгоритмов на предмет разночтений (сейчас повторно получаю текущей версией протокол, который не додумался сохранить), плюс добавить немножко изменений из плана, на которые времени хватит.

[Валерий Ж]

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

[vk65]

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

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

[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]

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

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

[lubezniy]

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

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

[vk65]

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

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

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

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

[lubezniy]

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

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

[lubezniy]

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

[vk65]

Сам не могу сказать - нет у меня доступа к реальным данным.

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

[lubezniy]

А какие результаты будут на объёме, меньшем на порядок (1000-1500 ЗЛ) ?

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

И ещё два предложения по интерфейсу:
1. Всё-таки хорошо бы писать не в TEMP, а задавать папку для выходных файлов.
2. Было бы удобно наличие кнопки, позволяющей повторно открыть сформированный протокол по выбранному страхователю.

Предложения дельные. К версии посмотрим, как лучше реализовать (по умолчанию хочу всё же оставить TEMP, ибо не всех пользователей эта проблема волнует).