ИзопропилSAX парсер
Можно же еще быстрее. Например XmlReader в C# у меня парсит 48 Мб за 2.1 сек. Если тупо прогнать цикл с подсчетом количества тэгов получается 0.3 сек. Читать блоками по 32 К - 0.01 сек.

Что-то параллелить с использованием XmlReader не очень получается. А с самодельным предварительным разбором можно было бы распараллелить и вместо 2.1 сек получить меньше 1 сек. Хотя и так устраивает.

Dimitry SibiryakovDima TИсходный файл парсить не XML-парсерами, а просто как файл, самодельным парсером, блоками
по 32 К (одного буфера достаточно): прочитали, разобрали как текст, сбросили буфер в
конечный файл.
В результате имеем невалидный XML в файлах и оверхэд по вводу-выводу. В морг.

Файл получится валидный, про валидность было в конце того поста, откуда ты этот кусок вырезал.
Оверхэд не критичен, т.к. IO намного быстрее разбора.

Владимир2012Dima TЧто-то параллелить с использованием XmlReader не очень получается. А с самодельным предварительным разбором можно было бы распараллелить и вместо 2.1 сек получить меньше 1 сек. Хотя и так устраивает.Ну может быть кто-нибудь и реализует то, что мы обсуждаем.
Не исключаю, что в свою library для работы с xml включу возможность как создания логических блоков ..., так и параллельный парсинг, ... /а программисту решать использовать или нет/.
ИМХУ задача штучная поэтому решения должны быть штучными, поэтому нет смыла делать какую-то универсальную либу для решения уникальных задач. Обычно гигабайты в XML никто не передает, для таких случаев есть другие варианты.

Касаемо приведенных цифр - это реальная стыковка с конкретной чужой системой и там размер XML ограничен не мной, а писателем, им сложно писать больше разом, сами попросили адаптировать прием под несколько файлов, вместо одного большого (200+ Мб) т.к. у них при генерации в один XML все падает. Они пишут медленнее чем я обрабатываю, поэтому ускорять нечего.

ИзопропилDima TЕсли тупо прогнать цикл с подсчетом количества тэгов получается 0.3 сек.
entity коды АСПушкин будет обрабатывать?
Это ты о чем?