Leonid Kudryavtsev,

выделять на стеке только object String, без буффера - те же яйца, но в профель. Все равно будет heap гадится.
Нет, только буфер. TmpStringBuilder

2) непонятно, что делать с функциями возвращающими строки. Теоретически, побороться можно, практически - фиг знает как реализовать. Или будет копирование туда-сюда обратно между кадрами стека или нужно память под возвращаемое значение в кадре вызывающей процедуры выделять (и передавать не явным парметром), но опять таки,

В верхней функции создаем TmpStringBuilder и передаем во все вызываемые процедуры как параметр.

азмем буффера под строку заранее не известен (и даже, может меняться).
Если его зафиксировать константой, то должно получится.

Доступ к i-му элементу тоже возможен но это будет как-раз отступление от потоков и движение в
сторону других строк.

Уж лучше я на буфере фиксированного размера буду работать.

Нужно как-то уметь понимать и обрабатывать объекты покидающие/могут покинуть (аналог escape-анализа) Thread.

Этого мало. Нужно убивать TmpStringBuilder при завершении функции, в которой он объявлен, не потока, а функции.

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

Leonid Kudryavtsev,

Ну напишите свою реализацию String'а на non-heap memory + подсчет ссылок

Ничего считать не надо, всегда удаляем по выходу из процедуры.

mayton,

А в твой буфер можно будет положить utf-8 ?

Суть предложения дать возможность выделять на входе процедуры буфер в стеке с его автоматическим освобождением при выходе из нее. Класть туда можно что угодно, для UTF-8 можно отдельный класс сделать.
Хотя я бы этот utf-8 использовать бы не стал.

Все равно на выходе из самой верхней функции вернет String tmpBuf.ToString (), выделяя под этот String место в обычной куче. По производительности - не хуже чем сейчас. Зато не будет на каждую операцию со строкой мусорить в куче умершими StringBuilder-ми.

Кстати, в UI приложениях этот ваш сборщик мусора бесит больше долгих операций по нажатию кнопки. Пользователь может понять, почему ему приходится ждать, когда он что-то приказал сделать, нажав на кнопку. Но когда он не делает ничего, а программа начинает вдруг шуршать диском и зависать - это реально бесит.

Вот сижу я в Firefox, никого не трогаю, смотрю сайт, просто текст читаю. И вдруг эта сволочь начинает виснуть сама по себе и шуршать диском. Не знаю, что оно там вообще делает, мусор собирает или еще что, но раздражает изрядно.

mayton,
мы же заботимся об упрощении работы программиста. С UTF-8 работать сложнее, потому что он не является массивом символов с произвольным доступом и дольше по той же причине.

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

Обсуждать "твою" тему в этом топике - за рамками добра и зла.

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