Владимир2012А вот если читаем 100MB и стартуем thread, который парсит эту часть xml, ... - будет наверняка быстрее.
Во-первых не ждем загрузки всего xml.
И что самое главное не один thread парсит xml, а несколько одновременно.
Допустим прочитали мы ровно 100 Мб и на конце получили обрубок чего-то. Вторые 100 Мб начинаются вообще непонятно с какого места, т.к. это мы узнаем только по окончании разбора первых 100 Мб, как начинать работать второму потоку?

Допустим это исходный XML, красным точка разрыва (по слову images)


Как тут второму потоку начать работать?
Допустим добавили какое-то выравнивание по началу ближайшего тэга (<img> например), но как узнать что мы находимся в table/tr/td ? Без этого знания проблематично обрабатывать.



ИМХУ если уж параллелить, то по-другому:
1. один поток читает файл и пишет в память до получения законченного блока, например <table>...</table>, блок ставит в очередь на обработку, и т.д. поблочно до конца файла. Читать он будет все равно медленнее чем блоки искать.
2. пул потоков, которые вынимают из очереди блоки и делают полный разбор

Тут без знания структуры не обойтись, допустим это одна большая таблица с кучей строк


тут получение блока <table>...</table> не даст никакого параллелизма, т.к. он один, надо изначально задать что бить на строки, т.е. блоки table/tr.

Дальше скорее всего потребуется задание нескольких обработчиков различных типов блоков, например если таблиц 3 то для строки каждой надо свой обработчик, т.е. разбирающие потоки должны для table1/tr запускать parser1(), table2/tr - parser2() и т.д.