А ты понимаешь, что другого пути нет и все остальные языки "с поддержкой строк на уровне
языка" делают под капотом всё то же самое?

Это - предположение. 99% это зависит от того как будет написан код поточного метода.
Он может работать со старой версией строки создав предварительно ее копию.
Он может работать с референсом на строку для immutable strings.
Мы можем ввести понятие версионной строки и отслеживать некое
атомарное состояние счетчика транзакций над строками. И все это
автоматизировать.

Кстати здесь я еще больше согласен с Сидоровым что строка это все-таки
не массив char[] как бы мне этого не хотелось.

Вобщем.. исходя из наблюдения. Больше блокировок на I/O, Networking чем собстенно на
строковых объектах.

petravВы понимаете что этот вызов normalize() - это два обращения к подсистеме динамической
памяти и эти обращения блокируют все потоки, которые в это время тоже вызывают new/delete
и тому подобное.

Исходя из старых практик разработки UI.
Нету прямой интеракции UI и объектов мультипоточности. Обычно создается некий
транспортный объект Model. Этот модел бегает туда-сюда от пользовательской формочки
к объекту представляющему собой WorkerProcess(Thread). Блокировки резольвятся на классичесокй
optimiztic/pessimistic transaction и мы выбираем тот режим который будет комфортным для конечного
пользователя или тот режим который будет гладко ложиться на бизнес-процесс.

Представить себе ситуацию что пользователь с высокой частотой долбит через UI по объектам
процессов мне сложно.

Посмотрите как работают high-load социальные сети. Если бы графические объекты хоть что-то
блокировали то весь фейсбук сидел бы 100% времени в блокировках.

PetroNotC Sharp, я прошу прощения. Случайно изменил твой пост. Как откатить - не знаю.

Но - перепость заново а я старый удалю.

Стоп. Давай немного отложим обсуждение фейсбука.

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

Просто обычный казуальный пользователь вводя неспеша с клавиатуры буквы просто
физически не успевает ничего сильно заблочить. Или у тебя просто неверно разработана
архитектура твоей Юайки. Подумай о optimiztic.

Расскажи что у тебя там под капотом.

Я прошу прощения. Ты можешь мобилой сфоткать твой UI ?

Без торговых обозначений. Без лейблов. Просто какой-то функционал.
Я просто пытаюсь понять что за такая там у вас отрасль
где нужно UI так тесно интегрировать с динамической памятью и строками.

Насчет рантайма я не имею ничего против. Просто интересно где это критично.

А зачем UI в 100 Гц?

Я слышал что в топовых играх видяшки переключают front-back buffer до 120Гц. Но это игра. Где плавность
изменения графики - просто видно боковым зрением. И не более того.

А научные испытания на кроликах людях и обезянах показали что человек реагирует и осознает изменения
UI с периодом в 100 милисекунд.

Это примерно соответствует 10 герцам.

Можно и выше - но на реакцию человека и на принятие решения это не влияет.

Мне кажется но.. Microsoft Powe Point на на анимациях и спец-эффектах слайдов .. фейдингов
как раз и обеспечивает те самые 10 герц. Экономно. CPU не грузит. И люди довольны.

Как Anime-сериал прям.

Я в этом смысле наверное похож на Торвальдса. Я - инженер. И люблю решать
инженерные головоломки. И мне глубоко безразлина контора в которой
ты работаешь. И я очень удивлён тем что ты нашел (!) реально нашел
проблему аллокации строк на СТЫКЕ UI и динамической памяти.

Я - правда удивлен. И мне кажется что если мы глубоко копнём в твою
проблему ... она окажется вообще не проблемой а просто архитектурной
фичей которая фиксится быстро.

Ты вот думаешь что для comparison двух utf-8 строк тебе надо обязательно
ре-аллоцировать (malloc/realloc) память? А я вот так не думаю.

Мне вот кажется что мы в состоянии решить эту задачу алгоритмически.

Давай просто разделим понятия хранения (storage) utf-8 строк и их представления (representation).