Приветствую дорогие друзья. Пишу небольшую программку с графическим интерфейсом по парсингу *.log - файла. Файл имеет объём от 30 Гб. Так вот, не могу придумать, как к процессу парсинга прикрутить прогресс бар. Как вести отсчёт?Подкиньте идей пожалуйста.

если файл 30 гиг - то полагаю делать привязку к количеству строк не стоит! пока посчитает - заснем.
Предлагаю разбивать файл на кусочки и обрабатывать их после обработки каждого увеличивать переменную счетчика и выводить ее уже в удобном виде.

ZerG, т.е. на кусочки? Предварительно разбить перед парсингом файл, допустим, на 4 части и по мере окончания файлов считать прогресс бар?

Да! На форуме даже есть пример как делать! Кроме того куски файла мона обрабатывать в потоках что сократит время обработки!
Но вам бы я предложил разбивать не на 4 части а скажем 100. Вот вам и 100 процентный тулбар (ето при условии что у вас файл всегда 30 гиг) а то если на 100 частей разбить текстовый документ их трех слов…..

Фишка в том, что файл по размеру может варьироваться. Т.е. это пока 32 Гб, а там может быть и больше. Это же log прокси. Но идея со 100 файлами мне понравилась. Так-то у меня и сам парсинг идёт в отдельном потоке, а в другом GUI. Но с этим только недавно разобрался.

Ну так - в чем пролема то ? Узнать размер файла - одна строка!
Да и в целом при разбивке на 100 частей вам всеравно сколько будет в итоге весить файл 300 метров или 500

Может проще - по объему файла? Не важно файл обрабатывается кусками или построчно - сделать счетчик N количества обработанных байт. Размер файла N узнается заранее. N / M * 100% и есть ваш прогресс.

Кстати можно тогда уже и градацию добавить!
Мол если файлик меньше 100 метров делить на 10 итд

ZerG
речь идет о лог файле, который , я уверен, текстовой, в котором целевая порция информации для обработки заключена в строке (т.е. отделенных символом переноса строки). И автор желает обрабатывать такой файл построчно. Проблема подхода с разбиением файлов заключена в том, что делая file_obg.read(n_count_of_bytes) получаем кусок данных в котором не содержится челое количество строк. Т.е. если данный фрагмент разбить на строки, то на границе этого фрагмента мы не получим законченную строку, которая осталась в следующей порции данных. А значит ее нельзя достоверно обработать. ЧТо бы решить эту проблему нужно усложнить логику кода, что бы он мог эту не законченную строку закончить со следующей порцией данных.
Если все это делать только ради прогресс бара - нерационально.

Суть задачи объясню, чтобы картинка получилась. Есть log файл с прокси. Есть пользователи. Мне поступила задача, нужно сделать так, чтобы на выходе получился точно такой же лог файл, но уже без пользователя(пользователей), которого я выбрал. Выбор пользователя осуществляю чекбоксом в окне. Далее формирую список из пользователей(либо один пользователь) и нажимаю парсинг кнопку. Каждый элемент списка сравнивается с конкретной строкой на вхождение в неё(т.е. есть ли пользователь конкретный в этой строке). Если пользователя в строке нет, то эту строчку копируем в другой файл, иначе оставляем в этом лог файле. На выходе получаем, что есть обычный log файл и пропарсеный. Так вот, пропарсенный всегда будет иметь меньший размер, чем оригинал, в зависимости сколько пользователей надо удалить. Исходя из того, что в среднем время парсинга файла размером 10Гб на одного пользователя занимает 450 - 470 сек., то хотелось бы прогресс бар сделать.