Проблема производительности Java для длинного StringTokenizer - PullRequest
1 голос
/ 14 сентября 2011

У меня есть программа, которая читает и обрабатывает данные в виде необработанного текста String, используя StringTokenizer

Первоначально StringTokenizer содержит около 1500 токенов, и программа работает нормально.Однако необработанный контент увеличился, и теперь он составляет около 12 000 токенов, а потребление ЦП в значительной степени увеличивается.

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

В то же время я хотел бы спросить, будет ли обработка одной длинной длины StringTokenizer стоить больше ЦП по сравнению с обработкой 10 коротких StringTokenizer с.

Ответы [ 3 ]

1 голос
/ 14 сентября 2011

Использование StringTokenizer не рекомендуется в соответствии с StringTokenizer java doc . Это не считается устаревшим, поэтому его можно использовать. только его не рекомендуется. вот что написано:

"StringTokenizer - это устаревший класс, который сохраняется для совместимости. причины, хотя его использование не рекомендуется в новом коде. Рекомендуется что любой, кто ищет эту функцию, использует метод разделения String или вместо этого пакет java.util.regex. "

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

производительности из-StringTokenizer класса-против-сплит-метод-в-Явы

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

1 голос
/ 19 сентября 2011

Прежде всего, спасибо за ваше мнение.На прошлых выходных я провел стресс-тест с реальными данными, используя пересмотренную программу, и был очень рад, что моя проблема решена (большое спасибо AJ ^ _ ^).Я хотел бы поделиться своими выводами.

Изучив пример, упомянутый AJ, я запустил некоторую тестовую программу для чтения и обработки данных, используя StringTokenizer и "indexOf" (Regex даже хуже, чем StringTokenizer в моей ситуации).Моя тестовая программа посчитала, сколько мини секунд необходимо для обработки 24 сообщений (~ 12000 токенов каждое).

StringTokenizer требует ~ 2700 мс для завершения, а "indexOf" занимает всего ~ 210 мс!

Затем я пересмотрел свою программу таким образом (с минимальными изменениями) и проверил с реальным объемом в последние выходные:

Исходная программа:

public class MsgProcessor {
    //Some other definition and methods ...

    public void processMessage (String msg) 
    {
        //...

        StringTokenizer token = new StringTokenizer(msg, FieldSeparator);
        while (token.hasMoreTokens()) {
            my_data = token.nextToken();
            // peformance different action base on token read
        }
    }
}

А вот обновленная программа, использующая "indexOf":

public class MsgProcessor {
    //Some other definition and methods ...
    private int tokenStart=0;
    private int tokenEnd=0;

    public void processMessage (String msg) 
    {
        //...
        tokenStart=0;
        tokenEnd=0;

        while (isReadingData) {
            my_data = getToken(msg);
            if (my_data == null)
                break;
            // peformance different action base on token read ...
        }
    }

    private String getToken (String msg)
    {
        String result = null;
        if ((tokenEnd = msg.indexOf(FieldSeparator, tokenStart)) >= 0) {
            result = msg.substring(tokenStart, tokenEnd);
            tokenStart = tokenEnd + 1;
        }
        return result;
    }
}
  • Обратите внимание, что в исходных токенах нет нулевых данных.Если FieldSeparator не найден, «getToken (msg)» вернет ноль (как сигнал для «больше нет токена»).
0 голосов
/ 14 сентября 2011

Почему бы вам не попробовать новый класс Scanner?Сканеры могут быть построены с использованием потоков и файлов.Не уверен, что он более эффективен, чем старый StringTokenizer.

...