Dimitry SibiryakovВладимир2012если считаете, что это надуманная задача, которую нет смысла обсуждать, то возражать не буду.

Задача не надуманная, но её решение не принесёт счастья.

Вот смотри: у меня есть софтина, читающая и парсящая определённый файл. Она это делает на
скорости примерно 10 Мб в секунду. При том, что просто чтение этого файла с диска идёт на
скорости 100 Мб в секунду. Отсюда вытекает, что если я в этой софтине наворочу
многопоточность, очереди, совмещу чтение и обработку и таким образом доведу расходы
времени на собственно чтение до нуля, то получу общее ускорение в 10% максимум. Оно того
не стоит.

Про 10% не понял. В идеале ускорение в 10 раз.

Dimitry SibiryakovDima TПро 10% не понял. В идеале ускорение в 10 раз.
Нарисуй временную диаграмму работы. Программа секунду читает, девять секунд парсит. Если
засунуть чтение "под" парсинг, 9 секунд никуда не денутся, в конце ты получишь 9 секунд
работы вместо 10. 10%.

Если парсить в 9 потоков, то распарсит за секунду. Другой вопрос разрешает ли алгоритм парсить в 9 потоков?

maytonА по поводу моего варианта - его за 1-й проход следует разбить на куски и сохранить их:



Сам процесс резания - прекрасно совмещается со скачиванием (потоковые операции).

Орининал - грохнуть.
+1
ИМХУ просто и работать должно быстро при достаточном наличии памяти, т.к. в кэше ОС останется скорее всего.
Парсить можно начинать сразу после создания chunk-01.xml причем без всяких самодельных парсеров.

Dimitry SibiryakovDima TДругой вопрос разрешает ли алгоритм парсить в 9 потоков?

Как я уже сказал: не разрешает. Парсером работает автомат с состоянием и обработка блока N
зависит от блока N-1. И даже если бы автомат был без состояния, блоки не имеют
фиксированной длины и тупо найти начало следующего невозможно не распарсив предыдущий. О
чём тут тоже уже говорилось.

Это если тупо рубить по К байт, но если выделять логические блоки, независимые друг-от-друга, то можно.
Выделить блоки несложно, например явно задав разделитель, как выше предлагалось. Или перед разбором задавать какие-то правила что считать блоком, как я предлагал 20046249

Dimitry SibiryakovDima TВыделить блоки несложно, например явно задав разделитель, как выше предлагалось.

И тут мы получаем необходимость seek() и потерю потоковости или накопление блоков в
огромных буферах памяти, что, конечно, тоже вариант, но не из простых.

Зачем? Исходный файл парсить не XML-парсерами, а просто как файл, самодельным парсером, блоками по 32 К (одного буфера достаточно): прочитали, разобрали как текст, сбросили буфер в конечный файл. Если наткнулись на разделитель - сбросили до разделителя, закрыли, начали новый файл и т.д.

Такой парсер однопроходный и тормозить особо не будет. Все что ему надо делать - получать текущее местоположение в XML, например "list/row". Чтобы на его основе сгенерить конец закрываемого файла и начало следующего.

Описал упрощенно, но никаких seek() точно не потребуется, выравнивая в буфере будет достаточно.

Владимир2012или как вариант предоставить программисту саму на его усмотрение добавить в xml некоторые маркеры.
ИМХУ Если мы имеем возможность править XML на выходе у создателя, то можно сразу генерить отдельные файлы с завершенной структурой и не заниматься излишним разбором на получателе. Так проще всего.

Вобщем я к тому что не надо закладываться на какие-либо разделители. Надо исходить из того что их нет.

Владимир2012Dima TИМХУ Если мы имеем возможность править XML на выходе у создателя, то можно сразу генерить отдельные файлы с завершенной структурой и не заниматься излишним разбором на получателе. Так проще всего.То бишь будет какой-то main xml, содержащий /к примеру/ include-s с данными об подчиненных xml?
Можно так. По большому счету там надо знать какой файл на каком месте и сколько их всего.
Можно просто в имя файла дописать который из скольки.