Виталий

Сначала ответь себе на вопрос: "А нахуа мне это надо". Ответил? Молодец. А теперь реши, какую область ты хочешь избрать? Пентест, реверс-инжиниринг, аудит безопасности и мн.др. Толку от того, что ты будешь хватать всего по-немногу. Выбери узкую специализацию и прокачивай этот скилл. За какой срок? Зависит от тебя. Можно и за год не хило прокачаться, если пахать в этом деле по 18 часов в сутки. Ежели просто поиграться, возьми Kali Linux, закинь эксплойтик себе на android-смартфон, подними шелл и успокойся

Ой, ой, страшно.

Ну сами подумайте, что такое C#? Это CIL. А рантайм CIL'а ой как память сжирает.

Вообще, это всё к недавнему вопросу здесь о том, что должен знать хороший программист. А знать он должен то, с чем работает. Если бы Вы знали, что C# - это "виртуальный" язык, то есть реальной машины, которая исполняла бы его код не существует. Он компилируется в тот самый CIL, который исполнятся виртуальной машиной. Она же сразу резервирует какую-то память, мегабайт сто-стопятьдесят, дабы быстро расположить в ней вновь создаваемые объекты. К тому же, подгружается несколько весьма больших DLL от которых "стандартно зависит" .NET-приложение.

Впрочем, и на Си контролировать память не так уж и просто. Как минимум будет пол-метра оверхеда, если не резать ножом. К слову, .NET тоже можно резать ножём, но так же эффективно, как Си, ясное дело, не получиться.

Во "взрослой" студии есть анализ памяти - ANALIZE - Launch Perfomance Wizzard.
Возможно, течет через замыкания. Или сборщик не поспевает, попробуйте GC.Collect().

Хм, нужно устроится на работу.

Знаю один такой сервис, и там тупо сидят люди и постоянно переставляют симки в телефоны и вручную вбивают из них текст :D

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

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

Мой вариант:

while(true)
{
    Console.Write("Введите оценку студента:");
    var mark = Console.ReadLine();
    int mint;
    if(int.TryParse(mark,out  mint) && mint >= 0 && mint <= 100)
    {
        File.AppendAllText("C:\\text.txt", mark+";");     
        Console.Clear();
        return; // или break;
    }
    else
    {
        Console.WriteLine("Введена неверная оценка.Максимальная оценка 100");
    }
}

Ну, например так:

// some background thread code
Form1.Dispatcher.Invoke(DispatcherPriority.ContextIdle, new Action(delegate()
            {
                label1.Content="invoked from background thread";
            }));

Т.е. мы берем элемент UI, у него берем диспатчер и в этом диспатчере делаем инвокейшн процедуры. Можно еще использовать статический Application.Current.Dispatcher.

Ваша задача очень эффективно решается обычным файлом на диске (открытый с запретом lazy writes, либо принудительным flush после каждой записи). Если инструментарий (язык программирования и библиотеки) позволяет - откройте файл маппингом на память.
Индекс для таких запросов не нужен, ведь ячейки можно индексировать примитивно - (x+maxx*y). запрос 100x100 блока превращается в 100 быстрых чтений по 100байт. Если это оправдано, можно хранить не ячейки а блоки 100x100, тогда при чтении будет читаться в 4 раза больше данных но четырьмя чтениями. Но если блок данных экрана влезает в буфер опережающего чтения операционной системы (драйвере файловой системы) то такой метод хранения будет неактуален.

Любой другой метод будет медленный либо по записи (например хранить в базе не ячейки а блоки 100x100, соответственно при запросе блока будут считываться четыре соседних), либо медленный по чтению (хранить по одной записи на ячейку) и не эффективный по месту на диске.

ILMerge, Embedded Resources... Вы извращенцы, господа. Почему бы просто не сделать нормальный installer?