LINUX.ORG.RU

История изменений

Исправление peregrine, (текущая версия) :

Да, забыл отписаться по итогам тестирования (смотрел в профилировщике студии), у меня в одном файле в среднем 850 вложенных тегов (от 30 до 5000 в выборке на 4 гигабайта), чисто по тегам если разницу измерять, то будет примерно в 2,5 раза между XmlReader-ом и XDocument-ом (правда этот тест не я делал, а нагуглил в интернете в виде таблицы для 10, 100, 1000, 10000 вложенных тегов, так что могли и сильно соптимизировать за 6 лет с момента бенчмарка). Но суть не в этом, а в том, что как ты и говоришь, само время парсинга у меня занимает 15% от общего времени работы программы (это без асинхронщины и тредов), а IO 75% (остальное это всякая уборка мусора, сохранение результатов, вывод логов в консольку куда я в тесте писал xml-ки которые не совсем xml-ки и так далее). Итого смысла увеличивать скорость обработки на 7% смысла нет, проще фоном через async обрабатывать потихоньку и не задумываться особо о том, что какие-то копейки можно оптимизировать, чтоб другие программы меньше лагали (в асинхронщине вообще пофигу по идее поскольку парсинг в своём треде живёт и если он меньше чем io то упора в него не будет, единственное на время работы отожрёт 1 ядро у других процессов ОС).

Исходная версия peregrine, :

Да, забыл отписаться по итогам тестирования (смотрел в профилировщике студии), у меня в одном файле в среднем 850 вложенных тегов (от 30 до 5000 в выборке на 4 гигабайта), чисто по тегам если разницу измерять, то будет примерно в 2,5 раза между XmlReader-ом и XDocument-ом (правда этот тест не я делал, а нагуглил в интернете в виде таблицы для 10, 100, 1000, 10000 вложенных тегов, так что могли и сильно соптимизировать за 6 лет с момента бенчмарка). Но суть не в этом, а в том, что как ты и говоришь, само время парсинга у меня занимает 15% от общего времени работы программы (это без асинхронщины и тредов), а IO 75% (остальное это всякая уборка мусора, сохранение результатов, вывод логов в консольку куда я в тесте писал xml-ки которые не совсем xml-ки и так далее). Итого смысла увеличивать скорость обработки на 7% смысла нет, проще фоном через async обрабатывать потихоньку и не задумываться особо о том, что какие-то копейки можно оптимизировать, чтоб другие программы меньше лагали (в асинхронщине вообще пофигу по идее поскольку парсинг в своём треде живёт и если он меньше чем io то упора в него не будет).