Владимир2012Вопрос в другом.
Вот скажем загрузили в memory xml размером 10MB.
Что будет более эффективно.
Парсить его в 1 потоке или параллельно в нескольких?
Вопрос действительно в другом. Вопрос куда дальше результаты разбора пойдут? Готово ли конечное хранилище (пусть даже промежуточный кэш) параллельно принимать распарсенные данные на бешенной скорости?

Давай определимся сначала какая скорость есть и какая нужна.

Владимир2012Единственно что могу пока сказать - верю, что распаралелить парсинг можно.
С дуру можно и ... сам знаешь что.

Распараллелил тут одним по их же просьбе, а их админы с претензией: "какого уха ты нам сервер ложишь?" Да, на 100% загрузил им все ядра на пару минут несколько раз в день, но сами ведь просили чтоб максимально быстро было однопоточно было ~10 минут, но остальное работало.

Это я к тому действительно ли это нужно.

Владимир2012Dima TЭто я к тому действительно ли это нужно.Из того, что вы сказали ИМХНО нужно предусмотреть возможность получения парсером свойств типа:
- одно поточный или параллельный парсинг;
- max количество задействованных процессоров и потоков;
- режим фонового парсинга /чтобы парсинг не властвовал над всем и вся/.
...
...
Я уже писал выше что подобные вещи пишутся "под заказ", можно наворотить все что угодно, но писать надо с нуля, не может быть супер быстрого парсера на все случаи жизни. Если важна скорость, то надо писать под конкретную задачу, а не универсально.

Возможно кто-то написав 100500 супер-быстрых парсеров найдет их общее место, обобщит и сделает свой. Но этот путь надо сначала пройти, затем делиться результатом, а не наоборот сначала придумать решение, а потом ждать оценки эффективности его применения.

Владимир2012Кому нужно будет тот обсуждать не будет, а возьмет и реализует.
Вердикт из этого пока один - ждем решения от того кому это будет нужно.
Неправильный вердикт. Если кому нужно не сможет, то обратиться - поможем, но нужна конкретная задача, а не оптимизация сферического коня в вакууме.