Ответ 1

Если разумно внедрить этот метод в класс, который не разделяется нитями, тогда вы можете повторно использовать буфер:

char [] oldChars = new char[5];

String stripControlChars(String s)
{
    final int inputLen = s.length();
    if ( oldChars.length < inputLen )
    {
        oldChars = new char[inputLen];
    }
    s.getChars(0, inputLen, oldChars, 0);

и т.д...

Это большой выигрыш - 20% или около того, так как я понимаю текущий лучший случай.

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

Ответ 2

с использованием массива 1 char может работать немного лучше

int length = s.length();
char[] oldChars = new char[length];
s.getChars(0, length, oldChars, 0);
int newLen = 0;
for (int j = 0; j < length; j++) {
    char ch = oldChars[j];
    if (ch >= ' ') {
        oldChars[newLen] = ch;
        newLen++;
    }
}
s = new String(oldChars, 0, newLen);

и я избегал повторных вызовов s.length();

другая микро-оптимизация, которая может работать,

int length = s.length();
char[] oldChars = new char[length+1];
s.getChars(0, length, oldChars, 0);
oldChars[length]='\0';//avoiding explicit bound check in while
int newLen=-1;
while(oldChars[++newLen]>=' ');//find first non-printable,
                       // if there are none it ends on the null char I appended
for (int  j = newLen; j < length; j++) {
    char ch = oldChars[j];
    if (ch >= ' ') {
        oldChars[newLen] = ch;//the while avoids repeated overwriting here when newLen==j
        newLen++;
    }
}
s = new String(oldChars, 0, newLen);

Ответ 3

Хорошо, я избил текущий лучший метод (freak solution with preallocated array) примерно на 30% в соответствии с моими мерами. Как? Продавая мою душу.

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

В любом случае мы идем:

    // Has to be done only once - so cache those! Prohibitively expensive otherwise
    private Field value;
    private Field offset;
    private Field count;
    private Field hash;
    {
        try {
            value = String.class.getDeclaredField("value");
            value.setAccessible(true);
            offset = String.class.getDeclaredField("offset");
            offset.setAccessible(true);
            count = String.class.getDeclaredField("count");
            count.setAccessible(true);
            hash = String.class.getDeclaredField("hash");
            hash.setAccessible(true);               
        }
        catch (NoSuchFieldException e) {
            throw new RuntimeException();
        }

    }

    @Override
    public String strip(final String old) {
        final int length = old.length();
        char[] chars = null;
        int off = 0;
        try {
            chars = (char[]) value.get(old);
            off = offset.getInt(old);
        }
        catch(IllegalArgumentException e) {
            throw new RuntimeException(e);
        }
        catch(IllegalAccessException e) {
            throw new RuntimeException(e);
        }
        int newLen = off;
        for(int j = off; j < off + length; j++) {
            final char ch = chars[j];
            if (ch >= ' ') {
                chars[newLen] = ch;
                newLen++;
            }
        }
        if (newLen - off != length) {
            // We changed the internal state of the string, so at least
            // be friendly enough to correct it.
            try {
                count.setInt(old, newLen - off);
                // Have to recompute hash later on
                hash.setInt(old, 0);
            }
            catch(IllegalArgumentException e) {
                e.printStackTrace();
            }
            catch(IllegalAccessException e) {
                e.printStackTrace();
            }
        }
        // Well we have to return something
        return old;
    }

Для моей тестовой строки, которая получает 3477148.18ops/s vs. 2616120.89ops/s для старого варианта. Я вполне уверен, что единственный способ победить это может заключаться в том, чтобы написать его на C (возможно, не так) или какой-то совершенно другой подход, о котором никто не думал. Хотя я абсолютно не уверен, что время стабильное на разных платформах - по крайней мере, дает надежные результаты на моем ящике (Java7, Win7 x64).

Ответ 4

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

Ответ 5

IANA низкоуровневый java-уровень junkie, но вы пробовали разворачивать свой основной цикл? Похоже, что он может позволить некоторым процессорам выполнять проверки параллельно.

Кроме того, этот содержит интересные идеи для оптимизации.

Ответ 6

Я был настолько свободен и написал небольшой ориентир для разных алгоритмов. Это не идеально, но я беру минимум 1000 прогонов заданного алгоритма 10000 раз по случайной строке (по умолчанию 32/200% непечатаемых). Это должно заботиться о таких вещах, как GC, инициализация и т.д. - не так много накладных расходов, что любой алгоритм не должен иметь хотя бы один прогон без особых помех.

Не особенно хорошо документировано, но хорошо. Здесь мы идем - я включил оба алгоритма с храповым уродством и базовую версию. В настоящий момент я произвольно инициализирую длинную строку длиной 200 символов с равномерно распределенными символами в диапазоне [0, 200].

Ответ 7

почему использование имени набора символов "utf-8" напрямую дает лучшую производительность, чем использование предварительно заданного статического const Charset.forName( "utf-8" )?

Если вы имеете в виду String#getBytes("utf-8") и т.д.: Это не должно быть быстрее - за исключением некоторого лучшего кэширования - поскольку Charset.forName("utf-8") используется внутри, если кодировка не кэшируется.

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