LamerFromSpace

включил оптимизацию, время добавления элементов сравнялось, потребление памяти упало на обоих до 176 МБ

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

Можно подсчитать размер потерянной в пустую памяти кодом (для x86):

std::vector<uint32_t> ptrs;
ptrs.reserve(list.size);
for (auto node = list.head; node != nullptr; node = node->nextNode) {
    ptrs.push_back((uint32_t)node);
}

std::sort(ptrs.begin(), ptrs.end());

uint32_t wastedSpace = 0;
for (uint32_t i = 1; i < ptrs.size(); i++) {
    wastedSpace += ptrs[i] - ptrs[i - 1] - sizeof(D1List<int>::Node);
}

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

блин интересно, я даже попробовал :D
https://codepen.io/anon/pen/gJPZmE?editors=1010
короче оказывается что keydown не отлавливает кнопку принт скрин, а keyup уже ловит евент ПОСЛЕ ТОГО, как скриншот сделан, ну и в скрине состояние страницы до того как обработчик сработает

так что да, никак

Зайдите в реестр:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.расширение файла\OpenWithList

Там откройте "папку" с именем .TORRENT и удалите лишнее.

Очевидно что это ссылка на указатель.
Ссылка позволяет менять значение переменной вне вызываемой функции. Укатаель, который вы передадите первым параметром функции, будет изменен на newArray.

Немного усложните программу, например написав парочку функций, которые определяют еще несколько переменных и что-нибудь в них пишут. В main() вызовите эти функции, а затем объявите test и выведите его значение. Вот тогда у вас гарантированно образуется мусор. При компиляции, нужно еще предотвратить оптимизацию компилятором (опция -O0), а то он может выкинуть вызовы функций, если посчитает, что они не влияют на дальнейшее выполнение программы.

Что бы понять происходящее, почитайте как работает стек.
Автоматические переменные определяются на стеке. Одно и то же место на стеке в разное время выполнения программы могут занимать разные переменные. Если вы не инициализируете автоматическую переменную, то она принимет то значение, которое уже лежит в области памяти, которую она занимает. Из-за того, что переменные имеют разный размер, то часто, например текущая 4 байтовая переменная (int) может занимать память, в которой до этого были 2 двух байтовые переменные, или любые другие вариации.
Стек выделяется при загрузке программы (или при старте потока). В ходе выполнения программы стек не освобождается и не перевыделяется, поэтому мусор (данные от старых автоматических переменных) в нем образуется постоянно. При выходе автоматической переменной из области видимости фактического освобождения памяти не происходит - просто изменяется указатель на стек (регистр sp), т.е. при этом не происходит даже обращения к памяти. Поэтому все ранее сохраненные в стеке значения в памяти остаются. И когда вы определяете новую переменную без инициализации, она занимает ранее освобожденное место и принимает какое-то значение (мусор), которое ранее было сохранено в эту область памяти.

Ну только такие методы не должны классу user принадлежать. Было бы лучше создать новый класс, вроде Database, который используется для хранения пользователей. А уж у этого класса можно сделать методы вроде find или sort. Только сигнатура этих методов уже разумеется никаких векторов не содержит: вектор -- это деталь реализации в данном случае, которая может быть изменена потом.