Несколько потоков для загрузки XML-файлов в память

Question

У меня есть набор файлов XML, которые я хочу загрузить в память для обработки.

Я загружаю файлы в коллекцию, и кажется, что это происходит намного быстрее, если я загружаю файлыв одном потоке, а не в пуле потоков.

Я бы подумал, что это было бы наоборот.

Почему использование нескольких потоков для загрузки файлов в память происходит значительно медленнее, чем если бы я просто перебирал список файлов и загружал каждый файл один за другим в один поток?

Это с C # .net 3.5

Код:

ICollection<XmlDocument> xmlFilesToProcess = new Collection<XmlDocument>();

foreach (FileInfo fileInfo in fileList)
{
     ThreadPool.QueueUserWorkItem(
        (o) =>
        {
            XmlDocument doc = new XmlDocument();
            doc.Load((string)o);
            lock (xmlFilesToProcess)
            {
                xmlFilesToProcess.Add(doc);
                counter++;
            }
        }, fileInfo.FullName);
}

Answer 1

Не видя код, трудно сказать. Если размер и / или количество XML невелико, а у вас только один ЦП, то может быть просто, что переключение контекста между потоками занимает больше времени, чем требуется для простого чтения файлов.

EDIT

Теперь, когда я вижу код, который вы создаете, слишком много потоков. Я предлагаю вам использовать Parallel.For TPL. Это доступно для .Net 3.5

См. http://msdn.microsoft.com/en-us/magazine/cc163340.aspx для получения дополнительной информации о TPL.

Answer 2

Не видя код, я думаю, это, вероятно, связано с тем, что чтение с диска является медленной частью операции. Поскольку диск действительно может считывать только один файл за раз, он становится узким местом.

Answer 3

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

Многопоточный код может быть медленнее из-за дополнительных издержек при синхронизации потоков. Даже если вы используете ThreadPool, начальные накладные расходы будут создаваться.

Трудно предложить, что лучше - однопоточное или многопоточное, не зная деталей проблемы, которую нужно решить.

Кроме того, трудно понять, почему один код медленнее другого, не видя код.