prog323

Следует различать потоки ОС и процессы в Erlang. Я не в курсе про C#, но насколько понимаю он делает потоки ОС (они очень тяжеловестные), чтобы сделать поток ОС надо сделать кучу дел.

Процессы Erlang в противовес потокам очень легковесны, например в памяти занимают минимум 512 байт, быстро создаются, быстро убиваются. ОС не знает об этих процессах, всю работу по обслуживанию (одновременному выполнению на доступных ядрах) берет на себя Erlang.

В ОС вы можете сделать ограниченное кол-во потоков, до 5000.
В Erlang вы можете множить процессы как вам вздумается, главное чтобы памяти хватило. Порядок числа 100000-1000000.

P.S. Добавьте тег Erlang.

Если не считают эти потоки сложную математику - Эрланг выигрывает 100%. Даже обсуждать не надо.

Для того, чтобы оценить где можно улучшить нужно в первую очередь посмотреть планы выполнения update и времена в профайлере SQL-сервера.
1. Каждый индекс отнимает время на своё обновление. Возможно можно уменьшить количество индексов. Иногда выгодней их удалять и заводить заново после операций обновления. Тоже касается вычислимых полей, значения которых хранятся в таблице. Если переделать ключ таблицы в кластерный индекс, то это может улучшить время поиска и обновления записей.
2. Тригеры. Их можно также отключить перед выполнением пакета и включить после выполнения.
3. Уменьшить количество операций Update путём их объединения по каким-то признакам. Уменьшить количество обновлений в одной транзации.
4. Если позволяет структура базы данных, то возможно быстрее будет работать связка delete/insert. В этом случае можно включить режим Bulk Insert, который пишет данные сразу в таблицы минуя лог транзакций.
5. Модель восстановления — simple, full или bulk logged. Возможно в вашем случае модель full даст выигрыш в обновлении данных, но вы можете потерять в месте на жёстком диске и времени сохранения базы данных.
6. Физическое расположение контейнеров. Можно физически разнести таблицы, индексы и лог на три разных диска - тогда могут улучшиться временные показатели.
7. Использование секционированных таблиц и индексов. Возможно, если обновление происходит только в определённой части огромной таблицы, например, только в записях последнего года, то имеет смысл разбить её на секции.

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

Вопрос скорости выполнения зависит слишком от многих факторов. В первую очередь от процедуры, которую вы хотите исполнять в потоке. Можно запустить одновременно множество потоков, но они будут упираться в ограничения в других местах - например, есть ограничение на количество подключений по сети, к БД, к жёсткому диску, ну, и собственно, количество процессоров.
Для исследовательских задач алгоритм улучшения примерно такой — сначала реализуете алгоритм, выполняющий поставленную задачу самым простым для реализации способом. Смотрите на времена выполнения, в частности можно и нужно использовать различные профайлеры, счётчики ресурсов и тп. Если после этого времена не устраивают - смотрите где происходят наибольшие потери — эти места и нужно править в первую очередь.
Повторюсь — улучшать нужно не то, что кажется исходя из каких-то там теоретических соображений, а то что реально показывает профайлер или трассировка выполнения.
Распределение вычислений по потокам может дать выигрыш в случае многопроцессорных систем (а может и не дать). При этом надо учитывать, что:
1. Потоки нужно создавать. Если расчётная функция выполняется сопоставимо со временем создания потока — нет смысла создавать поток.
2. Потоками нужно управлять. Им нужно передавать исходные данные, а также получать результаты. Потоки могут конкурировать и блокировать друг друга за ресурсы приложения, очереди с исходными данными или за способность записать результат.
3. Потоки могут быть независимыми или реализован конвейер. Во втором случае нужно правильно и согласовано организовать передачу данных между потоками — иначе все преимущества конвейерных вычислений уйдут в инфраструктуру обмена.

Можно реализовать следующим способом:
Запускается настраиваемое число потоков, которые в цикле берут данные из очереди типа ConcurrentQueue, обрабатывают их и результат кладут в кучу ConcurrentBag.
Указанные коллекции — потокобезопасные, то есть возможна безопасная работа с ними одновременно из многих потоков.
В моей задаче, для 4-х ядер оптимальное среднее время выполнения задачи с очередью 20000 элементов достигалось на 3-5 потоках.

Посмотрите Html Agility Pack, может подойдет.

var v = new
{
    token = token, 
    method = "abc", 
    param = new Dictionary< String, List<String> >() { { "data", new List<String>() { "nokia" } } },
    locale = "ru"
};

json = jss.Serialize( v );