mayton,

mayton,Если ты видишь какие-то performance-issues в будущем - то предоставь нам свои числовые оценки.
Насколько нас аффектит?

Технически - это вопрос об устройстве библиотечного API.
Их много было, и, несомненно еще будет.
Вероятно, твоя личная практика программиста в конкретный момент привязана к конкретному API,
по отношению к которому у тебя сформирована система ожиданий.
Предположим такие исходные:
- пишешь ты на Java.
- у тебя лично , а не вообще в мире, тонны кода, связанного с обработкой строк.
- этот код критичен - часть твоей собственной, специфической к предмету, утилитарной библиотеки специальных
алгоритмов обработки строк.
- и весь этот код базируется на ожидаемой гарантии того, что String.CharAt(i) работает с твоим кодом
за константное время, не зависящее от i.
(Предположим, что, сознательно или нет, ты заложился именно на это)

вопрос - что происходит с производительностью твоей, с годами и любовью выписанной библиотеки,
eсли происходит такой переход во внутреннем представлении строки на utf-8, который теряет гарантию константы для charAt(i),
и заменяет её на линейное от i время?

Это тоже гарантия, просто немного другая.
Сколько тонн кода после это ты признаешь как пригодное к переписыванию, и в скольких местах ты посчитаешь, что всё пропало?.
Сохранить такую гарантию - значить увелчить размер хранящего символ элемента.
Так и было сделано с самого начала в виде почти всегда заведомо излишнего двухбайтного представления.
Но двух байт теперь не хватает, надо шесть.
Правильное здесь решение - просто взять и увеличить размер char до 8-байтного целого?

Какую-то попытку ответа на это и пытаются давать в виде сжатого представления строки в новой java.
Но. а) это еще не завершенная реализация б) вопрос, заданный Eugene New она оивечает "неправильно",
и в этом есть своя правда - иначе любая конкатенация потенциально означает encoding,
но все со сваливанием в конце концов к "универсальному" представлению.
Универсальные строки строки плохо стыкуются гарантиями константного доступа к символа, только в обмен на расход памяти.

PS
Где-то в закромах ораклового публичного сайта валяется white paper от 2003 года, специфически строковым performance issues посвященная.
Efficient Use of pl/sql String functions for Unicode Applications
посмотри при случае, если не видел.

OoCcbooby,

Обработка текста основанная на индексом доступе? Можно пример?
любая функция выделения подстроки с пятого по двадцатый символ, там где она может быть построена на индексном доступе против случая, когда не может.

mayton,
о конкатенации речь не шла вообще.
и она не плохая и не хорошая. Просто операция на строках.
Очень замечтательно хорошая при разумном использовании.

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

Конкатенацией можно написать такую функцию, которая всю систему превратит в неработоспособную.
А можно ей же сделать так, что время формирования результата будет технически неотличимо от случая с заранее известным размером.
Сама по себе конкатенация - "ни в чем не виноватая"

Плохая конкатенация, это как плохое сложение числе.
Рано или поздно, в конкретном железе, оно становится "слишком дорогим".

OoCc,

я не понимаю что ты хочешь сказать.
Что все алгоритмы на строках по своему смыслу потоковые?
Предположим, что ты прав в космическом смысле и в мировом масштабе.

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

Существенно это или нет, и может ли алгоритм быть легко переформулирован
для сохранения своего класса времени работы в O-оценках - это всякий раз
специальный по отношению к алгоритму разговор.
mayton, вот не рискнул, с разбегу, от гарантий на время работы charAt отказаться.

И, допустимо считать, что в случае с твоим кодом, этот момент целиком не имеет значения.