Строка оптимизации Java по сравнению с массивами символов

Вы профилировали свое приложение? Вы знаете, где находятся узкие места? Это первый шаг, если производительность ниже номинальной. Ну, это и определение приемлемых показателей производительности.

После того, как вы профилировали выполнение некоторых задач, у вас будет процент времени, потраченного на выполнение этих задач. Если вы тратите много времени на манипуляции со строками, может быть, вы сможете начать кэшировать некоторые из этих манипуляций? Выполняете ли вы некоторые из них несколько раз, когда достаточно выполнить их только один раз (а потом снова использовать этот результат, когда он понадобится)? Вы копируете строки, когда в этом нет необходимости? Помните, что java.lang.String неизменяем, поэтому его нельзя изменить напрямую.

Я несколько раз обнаруживал, что при оптимизации / настройке производительности систем, над которыми я работаю, я инстинктивно не знаю, откуда берется медлительность. Я видел, как другие (и, к сожалению, я сам) тратили дни на оптимизацию чего-то, что не показывало никакой выгоды - потому что это не было первоначальным узким местом, а фактически было затрачено менее 1% времени.

Надеюсь, это поможет вам указать правильное направление.

Вот выдержка из полного исходного кода класса String из JDK 6.0:

 public final class String implements  java.io.Serializable,
       Comparable<String>, CharSequence {
       /** The value is used for character storage. */
        private final char value[];

       /** The offset is the first index of the storage that is used. */
       private final int offset;

        /** The count is the number of characters in the String. */
       private final int count;

Как вы можете видеть, внутренне значение равно уже хранится как массив символов. Массив символов как структура данных имеет все ограничения класса String для большинства манипуляций со строками: массивы Java не растут, т.е. каждый раз (хорошо, может быть, не каждый раз) ваша строка должна увеличиваться, что вам нужно чтобы выделить новый массив и скопировать его содержимое.

Как было предложено ранее, имеет смысл использовать StringBuilder или StringBuffer для большинства операций со строками.

Фактически следующий код:

   String a = "a";
   a=a+"b";
   a=a+"c";

При компиляции будет автоматически преобразован для использования StringBuilder, это можно легко проверить с помощью javap .

Как показывает практика, редко рекомендуется тратить время на попытки улучшить производительность основных классов Java, если вы не являетесь экспертом мирового класса в этом вопросе, просто потому, что этот код был написан экспертами мирового уровня в первую очередь. место.

Когда у вас очень большое количество коротких строк, использование вместо них char [] может сэкономить довольно много памяти, что также означает большую скорость из-за меньшего количества промахов в кэше.

Но с большими строками главное, на что следует обратить внимание, - это избегать ненужного копирования, которое приводит к неизменности String . Если вы много выполняете конкатенацию или замену, использование StringBuilder может иметь большое значение.

Строка уже реализована как массив символов. Что вы планируете делать по-другому? В любом случае, между этим и тем фактом, что сборщик мусора для эфемерных объектов работает очень быстро, я был бы удивлен, если бы вы нашли способ повысить производительность, заменив массивы символов.

Совет Майкла Боргвардта о небольших массивах символов и использовании StringBuilder и StringBuffer очень хорош. Но для меня главное - постараться не догадываться о том, что тормозит: провести замеры, воспользоваться профилировщиком, получить определенные факты. Потому что обычно наши предположения о производительности оказываются неверными.

Какие манипуляции вы делаете? Можете выложить образец кода?

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