Помогите пожалуйста. Опытным путем было вычислено, что память девается именно при использовании паралелизма.
Код имеет такой вид.  GetSubTextInformation() - тут находится парсер, который парсит текстовую информацию и возвращает уже готовый результат. Получается, что память уходит в никуда и такими обьемами что просто ужасть.
Parallel.For(0, textParts.Count, delegate(int i)
                 {
                  article[i] = parse.GetSubTextInformation(textParts[i], _textId, i + 1);
                 });

При замене на просто for все становится как надо, никто никуда не ищезает, все очищается, и прога при роботе не превышает в памяти размера в 25 метров. Если с паралельностью то доходит до гига и потом каюк. 

Слышал что для каждого потока создается как бы своя куча, (я думаю там мусор и накапливается). Но немогу понять как это сделать. пробовал:

Parallel.For(0, textParts.Count, delegate(int i)
                 {
                  using(Article article = parse.GetSubTextInformation(textParts[i], _textId, i + 1))
                  article[i] = article;
                 });

все рано галяк. Пробовал так же внутри цыкла вызывать GC.Collect() но все равно безрезультатно.

Помогите.

Bladerender, похоже, что память съедают не фигурные скобочки, так что без кода парсера тут нечего сказать.

Код парсера возвращает коллекцию строк.
Тоесть класс, обьект которого возвращается имеет вид типа:

class Name
{
public string Name;
public List<string> collection = new List<string>();
}

Bladerender, вероятно, какая-то проблема с разделяемостью ресурсов или thread-safety. Кстати, вместо String-массива пользуйтесь StringBuilder, когда создаёте строку. Это - общие соображения. А конкретно я бы попробовал-таки разделить ресурсы, то есть либо сделать парсер статическим, либо создать его экземпляров по числу вычислительных потоков и поставить в Parallel.Do. С другой стороны покрутите и свой вариант - всегда же можно вместо некоторых кусков кода наставить временных заглушек и тем самым локализовать проблему.

Делал статическим,  один перец. Нащет Parallel.Do, то пока не пробовал, но думаю что это все равно ничего не даст, так как потоки сами создают в Parallel.For по екземпляру на поток. Я в этьм почти уверен.

Не знаю, может поможет. Если у тебя внутри потока есть цикл, в котором создаются объекты - то сборщик мусора "старые" объекты удалит только после выхода из цикла. У меня такое было на загрузке фоток - вплоть до вываливания в нехватку памяти (когда более 2 гигабайт съедало). Мне помогло собственноручное удаление объктов внутри цикла.

Это сообщение отредактировал(а) rubbiroid - 26.3.2008, 01:23

Bladerender, 

окей, я для примеру написал генератор строк



и параллельно-последовательный тест с ним :



И ничего, апокалипсиса не наступило : в обоих случаях пик памяти - примерно 55 мб.

Я может, поскромничал, нужны более агрессивные условия?  Давайте, в общем, сделаем пример таким, чтобы описанное поведение воспроизводилось.

Присоединённый файл ( Кол-во скачиваний: 2 )
 StParGen.rar 23,81 Kb

Странно как-то получается. У меня Ваш код тоже работает нормально. Без апокалипсиса. Я разберусь что не так и вкину свой генератор.

Зачем же сразу выкидывать?! = Дайте его потестить, что ли...