Вот скажем нужно загрузить xml размером 1GB.
Можно ли каким-то образом организовать прием и парсинг XML несколькими процессами одновременно?

PS: Идейка вот такая появилась.
При формировании big xml добавлять в них некие служебные nodes, которые как-бы подсказывают ридеру XML, что части xml между
служебными nodes можно парсить параллельно.
Т.е. как-бы логически разбиваем xml на n частей, каждую из которых можно парсить параллельно.
Ну и конечно потом каждое из полученных деревьев линкуем к main three.

Владимир2012... парсинг XML несколькими процессами одновременно?Пардон.
Правильно где-то так:
"... парсинг XML несколькими thread одновременно?"

maytonПарсинг XML - это легкая операция.Имеются свои "заморочки" ...

maytonДумаю что скорость вычитвания тегов
будет близка к чтению дискового I/O.Дисковые операции всегда были на порядки медленнее работы в памяти.
Прочитать за раз 1CB /например если нам нужен DOM/ это один из подходов.
А вот если читаем 100MB и стартуем thread, который парсит эту часть xml, ... - будет наверняка быстрее.
Во-первых не ждем загрузки всего xml.
И что самое главное не один thread парсит xml, а несколько одновременно.

Владимир2012А вот если читаем 100MB и стартуем thread, который парсит эту часть xml, ... - будет наверняка быстрее.Кстати это суждение не сложно проверить:
Берем любой тестовый файл размером 1GB;
Пишем алгоритм, который читает 100MB и запускает thread, который скажем подсчитываем количество слов, ...
Thread работаем, а мы читаем следующие 100MB и ... /см. строчку выше/.

maytonВам наверное надо все-таки дать больше инфы о самой задачеДа конкретной задачи пока нет.
Просто этими днями появилась у меня необходимость разработать а-ля MSXML API совместимую library для работы с xml.

Взял за основу TinyXML2.
Дополнил ее классами а-ля MSXML ...
Собственно теперь TinyXML2 как-то неловко и называть TinyXML2 ... /выкладывать на github пока не буду/.

Так вот load() в TinyXML2 читает за раз весь XML.
Вот и пришла мысль, что для небольших xml такой подход сойдет, а вот для big xml скорее всего нет.

maytonНа этой печальной ноте наверное можно закрывать топик.А что тут печального?
Топик завел не потому чтобы рассказать о некоих своих велосипедах, а для обсуждения конкретного
алгоритмического вопроса.

Что бы не было вам печально подскажу где взять исходные тексты а-ля MSXML library.
В исходниках ReactOS имеется полноценные исходные тексты а-ля MSXML library /мне они не подошли/.

Что касается моего велосипеда, то кому он нужен?
Можно к примеру просто использовать готовое API Microsoft /и ни каких проблем/.

alexy_blackдисковые операции медленные еще и потому, что им нужно головку позиционировать. когда прочитаешь 100мб, потом какой-то другой файл прочитается (другим процессом), потом еще 100 - головку опять позиционировать... короче быстрее за раз его прочитать.Гм.
Да ведь речь идет не об нескольких процессах, а об одном.
Читаем 100Mb запускаем thread, продолжаем читать ...
Ну хорошо скажем так.
Читаем за одну операцию чтения весь 1GB и затем разбиваем 1GB на 10 частей, каждая из которых парсится отдельным thread.

maytonЕсли вы спецом пишете ПО под сервер где можете кидаться гигами
направо и налево - то наверное надо сообщить об этом в первых
строках сообщенияДа нет же.
Еще раз говорю.
Тема топика навеяна всего лишь обсуждением абстрактной задачи ...

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

Dimitry SibiryakovПроблема в том, что текстовый файл не разбивается. Нет к нему рандомного доступа, только
последовательный.Дмитрий.
Обратите внимание на то, что в начале топика мною было преложено дополнять xml некоими служебными nodes,
назначение которых состоит в том, что при считывании xml нам известны "логически правильные" части
xml, которые можем парсить в отдельных thread.
Sorry повторюсь.
Так вот эти служебные nodes как раз и решают ту задачу об которой вы говорите "... текстовый файл не разбивается. Нет к нему рандомного доступа, только
последовательный.".

Dimitry SibiryakovОтсюда вытекает, что если я в этой софтине наворочу
многопоточность, очереди, совмещу чтение и обработку и таким образом доведу расходы
времени на собственно чтение до нуля, то получу общее ускорение в 10% максимум. Оно того
не стоит.Вообщем то да.
Но заметьте парсинг идет с скростью 10MB в секунду, значит сколько времени понадобится для парсинга 100MB - 10 секунд.
А вот если ядрышки вашего процессора загрузить "по полной", а их у вас скажем будет 10,
То сколько времени понадобится для парсинга 100MB?
Не 10 секунд, а всего лишь 1 секунда.

Dimitry SibiryakovНе решают, поскольку для их нахождения файл надо распарсить.Да зачем его парсить?
Когда создается big xml программист знает в какие места xml нужно добавить служебные nodes.
Далее все просто.
За одну и операцию чтения читаем 1GB и далее находим в memory обычным циклом находим эти служебные
nodes.
И все!
После этого запускаем n thread каждый из которых знает какую часть xml он должен парсить.

Sorry. Еще раз.
Служебные nodes избавляют нас от необходимости парсинга всего xml ...

Dimitry SibiryakovВ твоём случае, для распараллеливания обработки, куски XML придётся обернуть в XDR, отчего
файл в целом уже перестанет быть XML-ем. Так, может, сразу не мучиться и вместо XML
использовать XDR, который и сам по себе парсится легче, да ещё и распараллеливается при
желании?..У меня "конкретной" задачи пока нет /обсужденение абстрактной задачи/.
Да безусловно имеются некоторые текстовые файлы, которые нельзя "разбить" на логические части так,
чтобы можно все эти части парсить параллельно.
А вот к примеру /экспромтом/ берем xml файл в котором находятся паспортные данные 10 000 000 человек и все
nodes однотипные.
В этом случае ИМХНО вполне можно разбить этот big xml на n частей, каждую из которых будет парсить отдельный thread.

PS: В целом конечно с вами согласен. Имеются "не разбиваемые" текстовые файлы /например текст огромной программы/ ...
Но имеются и не мало big текстов, которые пригодны для параллельной обработки.

maytonВладимир2012, так что ли?Да ... /и вариации на тему/.