ViPRos


эти срочки выключают мой ноут без предупреждения, в собтиях- неожиданное отключение и все.
В nproc - порядка по 250 000 inlinks и outlinks.

На ламера, который не знает как готовить linq

nproc = nTreeNodeDicSpecifId[specificid].ToList(); // ToList совершенно не нужен. Без него не будет сотен тысяч добавление в list c выделением памяти. На таких объемах - это полные тормоза
List<Guid> links = nproc.SelectMany(n => n.proc.proc_outlink).Select(s => s.linkid).Distinct().ToList(); // аналогично. За это нужно бить линейкой по рукам
Вместо (n.proc.proc_inlink.Count() == 0) должен быть (!n.proc.proc_inlink.Any())
|| заменить на Union
etc
etc

ViPRosАлексей К,

точно, я так и думал
даже машина говнокод не принимает блин

А это ты, Сахават, решил linq применить ;-) На таких объемах нужна оптимизация и понимание принципов linq. Посмотри оператор yield и для чего он нужен , тк весь linq на нем

ViPRosbeg-in-er,

ну я и говорю что говно, а при больших данных воще не пашет
а про Лист Сева наврал
все промежуточные расчет надо зафиксировать

ViPros, я не мсу. ToList перед Select это всего навсего:
- создание, выделение памяти под List
- совершенно лишний проход всего списка, тк последующий select делает тоже самое
- создание экземпляра класса с выделением памяти и добавление его в список, а это влечет большие мультики с расширением границ массива.

Если еще стоит where то разница будет весьма существенна.
Сделай простую проверку и сравни по быстродействию и памяти два варианта

var list = Enumerable.Range(1, 1000000).ToList();
var res = list.First();

и var res = var list = Enumerable.Range(1, 1000000);
var res = list.First();

После этого поэкспериментируй с where и другими операторами. Сразу почувствуешь разницу, тк во втором случае не происходит создания всего списка в 1000К, а после отложенного выполнения делается только один проход и сразу дается результат

ViPRosSeVa,

насчет отложенного я все понял, не зря читал про енумератор и yield ж
я говорю, что если во вложенном вопросе будет var, ienumerable и т.д.,
типа a.where(n => b.select(i=> b.id).contains(a.id)) то для Каждого элемента из а будет срабатывать b.select(i=> b.id)
а если сделать a r = b.select(i=> b.id).ToList(), то b.select(i=> b.id) будет один раз
это вдно прямо в дебагере и по скорости обработки

если нужны несколько проходов, то есть специально обученные техники для этого.
ЗЫ Сдается мне, что a.where(n => b.select(i=> b.id).contains(a.id)) можно заменить на простой join

ViPRosSeVa,

т.е все как было так и есть
скорость достигается за счет памяти
Естественно, для net - минимизация выделения памяти - первое, что нужно делать.

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

ViPRosу меня громадные массивы
сотни гигабайт для завода генерится при расчете портфеля :(

Тогда тебе нужны спецтехники для борьбы с ними. Опиши, что нужно

ViPRosLord British,

есть несколько вариантов записи

1. BulkCopy
2. Пользовательский тип
3. Просто Insert
batchsize можно менять как угодно во всех случаях
счас самым удачным является 2

ну тут дело в том что эти данные тут же должны быть доступны для обработки
это запись-чтение тут же
по хорошему воще должна быть запись одиночка (это воще убивает СКЛ сервер)
(ну типа заблокировал процессорпроцесса на какой то отрезок и эта инфа сразу должна быть доступна другим потокам - возможо на другом компе запущенным)

Для цепочек параллельных вычислений сейчас появилась весьма интересная штучка - dataflow

ViPRos(ну типа заблокировал процессорпроцесса на какой то отрезок и эта инфа сразу должна быть доступна другим потокам - возможо на другом компе запущенным)

Посмотри streaminsight

ViPRosSeVa,

про какой то dryad читал, но нет там демо и кажется сиильно платный
почитал erlang - замахаешься кониги делать
wcf лучше подходит кажется

да, dryad платный, бета и на него уже забили. будет haloop.