SiemarglПроблема в другом - там где можно обойтись стековым размещением, тебя принуждают к хипу.

Ну это да. Но это сейчас во всех языках такое
Объект на объекте, шаблон на шаблоне, паттерн на паттерне сидит и паторном погоняет

Сейчас популярны immutable объекты. Все immutable. Нужны были вычисления над датой/временем - жесть. Любая операция, immutable объект, создавайте новый. Пришлось стандартные классы выбросить в помойку, взять библиотеку которая поддерживает нормальные muttable объекты.

При такой концепции, ты хоть в стеке их выделяй, хоть в хипе ))) Результат будет одинаковый

В Java ввели ByteBuffer'ы вне heap'а. По доке, якобы для того, что бы при вводе-выводе через NIO ф-ции избегать лишнего копирования из памяти в память.... Блин... смотрел реальный код, реальной библиотеки... все стало еще хуже. В процессе ввода-вывода, копирований туда-сюда-обратно из одного ByteBuffer'а в другой, минимум 3-5 раз происходит. (Apache HTTP Components, NIO)

Работа со стандартными объектами, например строками. Все поля private. Объекты immutable. Хочешь получить доступ банально к массиву символов, что бы codepage преобразовать... ан нет... фигушки... private, инкапсуляция... сделайте новый массив и скопируйте

Думаешь, что это ты сам дурак..... смотришь чужой код в I-net'е, в коде один сплошной Unsafe пакет ))) Что ни чих, то недокументированный Unsafe )))

SiemarglА локальных одноразовых переменных на порядок больше, чем долговременных.

Поэтому есть eden и old gen области. С разными GC алгоритмами

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

А когда подход к настройке enterprise серверов:
"Там автоматик мемори менеджмент, Oracle умный, ему виднее" ( C ) админ Oracle Database
то и результат соответствующий

kealon(Ruslan)Leonid KudryavtsevC, C++
Не очень быстро ))) выделяют (new) и не очень быстро освобождают (delete)
с чего вдруг такое?
А сейчас что-то изменилось?
Лет 10 назад, операции new и delete в C не были "бесплатными". В отличие от Java, C#.

Поэтому на ряде тестов ))) С#-ты радостно кричали: "смотрите какой у нас быстрый язык, C полный отстой" )))

qq2017только стэковая память и объекты со счётчиком ссылок(shared_ptrы и т.п)

Вы уж определитесь: или только стековая память и без heap'а или heap )))
qq20172) То же самое на обычном языке со сборщиком мусора(C#/java/python)

1. То же самое не получится. По __определению__.
2. Все зависит от кривизны рук программиста

В случае реализации паттерна "сортировка пузырьком" - разницы не будет.

Изопропил...
new - просто увеличение указателя вместо поиска оптимального участка
В Java там теперь зачем-то еще блокировки ставят

Они в спецификацию какую-то хреномунтию наворотили для immutable объектов с final полями

Вроде new для ситуации immutable объекта когда все поля final атомарна по определению и не требует synchronized{ }. Но я в этих дебрях "плаваю". Читал просто какой-то ресеарчь от авторов Java, где они разбирались, сколько же в результате они из-за этого в производительности потеряли на разных типах процов.

Особенно мне понравилось место по середине, где они английским по белому написали "б№;%#дь, там мы здесь же в коде new ошиблись и не ту инструкцию синхронизации используем" ))), после чего я понял, что моих поверхностных познаний по блокировкам достаточно.... нафиг их улучшать, если даже авторы java тоже в них ошибаются )))

В общем, закрыл книжки, скопи пастил из I-net работающую Single Producer Single Consumer очередь и на этом успокоился )))

kealon(Ruslan)....
в современных менеджерах памяти то же самое почти
затести, 40 млн. выделений/сек выдаёт на 4+ потоках?

Приводи код теста (+ желательно скомпилированный бинарник под Windows, у меня C на компе не стоит)
Затестим

А пока, 40 миллионов сферических коней. Мне вакуум на них тратить жалко.