Читается огромный файл и хотелось бы хоть как-то сделать прогресс бар. Никак не узнать количество узлов или хоть какую-то инфу о размере файла, ходе выполнения?

а как читается то?

(1)+ можно, например, через ДокументDOM, там есть методы подсчета количества узлов

если файл делаешь сам, то в корневой элемент засунь количество объектов атрибутом. если не сам, то тогда только, если читаешь не через чтениеХМЛ, оно хорошо тем, что работает последовательно и по этому не жрет памяти, но узнать что-то "вперед" - нереально

(1) Просто ЧтениеXML


    ЧтениеXML = Новый ЧтениеXML;
    ЧтениеXML.ОткрытьФайл(ИмяФайла);
    Пока ЧтениеXML.Прочитать() Цикл

(3) выгрузка КД, не хотелось бы её курочить

(0) чтением XML нельзя, как я понимаю. Оно читает от начала и до упора, количество там никак не прогнозируется.

(0) Прикинь размер файла относительно количества элементов, примерно высчитывай.

(0) Узнать длину файла. Попробовать опоеделить длину строки XML считанного узла. Сделать поправку на число байт в символе и ты получишь примерное положение в файле. Плюс минус разделители строк.

(0) Или одновременно с чтением записывай прочитанное куда-нибудь строками. Длина записанного будет прогрессом.

(0) Или открыть файл дважды. Читать как текст и параллельно - как xml. Хотя, не уверен, что чтениеxml такое позволит...

может так, грубо...
СтрЧислоВхождений(ТекстXML, "<" )

(11) Некошерно, надо весь файл в память считывать. Тогда уж можно и точно посчитать...

Похрен, буду выводить количество прочитанных узлов. Если каждый день делать эту загрузку, то примерное количество всех будет уже известно

В (2) правильный ответ, если, конечно, файл не гигантского размера.

(5) Все таки решил курочить?

Но если файл действительно огромный, то есть еще потоковое чтение данных. Там можно порциями выбирать куски файла (примерно как перебирать выборку запроса), и обрабатывать их. При выборе куска файла система возвращает его содержимое и размер. Размеры накапливаем в какой-то переменной, делим на общий размер файла, умножаем на 100 и таким образом получаем проuhtcc обработки а процентах.

200 метров - это огромный?

(23) Тут правильнее мерять не в метрах, а в количестве узлов. Если там 10 узлов по 20 метров каждый, то не много, а если 20000 узлов - то много.

(25) около 5млн узлов

(25) Это важно для предлагаемого вами чтения всего файла и построения в памяти структуры dom?

(26) Тогда чтобы прочитать это через DOM, надо будет сначала все загрузить в оперативку. Скорее всего заглохнет.

(28) Но это же только что был правильный вариант! Как же так, Юрий?

(27) Да, это важно. Вся эта структура не нужна в оперативке, тем более, что там 5 млн узлов. В этом случае логичнее пробовать потоковое чтение.

(29) Внимательно перечитываем (14), особенно последние 6 слов. Или с первого раза не дошло?

(31) Юрий, я вас не понимаю. То есть, согласно (25), если файл в 200 мегабайт, состоит из 10 узлов с двоичными данными, то он не огромный и ваше (14) применимо, а если в файле в 200 мегабайт 5 млн текстовых узлов, то он огромный и надо читать последние 6 слов?

сейчас прогресс бар с конечным состоянием практически никто не делает. делай просто крутящийся кружок и колво загруженых

(32) Да, все верно, учитывая, что по условию задачи надо посчитать количество узлов.

200м вроде не много должно занять в памяти. можно прочитать кол-во узлов. закрыть и далее читать стандартно

(35) Проблема как раз в количестве узлов. DOM при 5 миллионах скорее загнется с большой долей вероятности. Хотя ТС может это легко проверить за 15 минут на своем севаке.

(26) и кто будет смотреть на этот прогрессбар?..
Сделай, как в типовых обменах данными реализовано, - там просто кружок, который вертится постоянно, символизируя, что все работает и ни чего не сломалось.

(37) С прогрессбаром можно посчитать примерное время окончания обработки файла, иногда это бывает полезно.

(38) ну, узнал ты, что это будет через час. Дальше что?
Кому это может пригодиться и зачем?
Такие штуки должны происходить сами где-то на сервере без пользователей. А серверу прогрессбары не нужны

Серверу и 1С в принципе не нужна.

Пользователю нужно оповещение по электропочте или смс о завершении работ )

А может быть прогресс бар и не потребуется?
http://catalog.mista.ru/public/311011/

"Что касается быстродействия..., то на файле 10 000 записей полная обработка заняла 30 секунд  и на файле в 100 мегабайт линейно увеличилась в 10 раз."

"Этот метод немного проще чем простой перебор узлов в DOM документе, но быстродействие... При 10 000 записей 69 секунд , а для 100 000 обработка длилась более часа, так и не завершилась, после чего была снята принудительно."

"Пятый метод схож с предыдущим, но глобальной фабрике XDTO подается на вход не только сам XML документ, но и его тип... Метод замечательный, как по простоте создания, так и по быстродействию – 3,1 секунды на 10 000 записях."