Как стать автором
Обновить

Комментарии 35

Так и сделали бы топик-перевод.
Наши собственные методы добились 15% увеличения количества операций в секунду по сравнению с «new String(byte[])» и 30% увеличения количества операций в секунду по сравнению с «bytesToStringUTFNIO(byte[])».
В итоге, наши методы добились в общем 45% ускорения
Откуда здесь 45%?
Во первых сначала говорится про увеличение на 15% и 30% кол-ва операций в секунду (а это 13% и 23% прироста скорости обработки соответственно), а потом сразу переход на ускорение.
Во вторых в лучшем случае прирост производительности не может быть больше чем 23%, а если используются оба метода — то и того меньше.

А то получается изначальный автор таким хитрым софизмом более чем в два раза увеличил процентные показатели эффективности своего метода.
Справедливости ради надо уточнить, что местами статья действительно вызывает какие-то сомнения. Однако то, что выигрыш есть, несомненно — лично померял.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Неправильно подозреваете. Одинаково работают. Можете проверить.
Совсем недавно я приводил пример, когда метод в три раза длиннее по байткоду компилируется один-в-один, как и короткий метод.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А можно еще ускорить процентов этак на 50, если избавиться от str.toCharArray(); и пользоваться str.charAt().
НЛО прилетело и опубликовало эту надпись здесь
Потому что проверял и знаю.
А еще это вполне логично даже из общих соображений: toCharArray() создает новый массив, увеличивая нагрузку на память и копируя символы лишний раз, в то время как charAt() достает символ непосредственно из строки.
НЛО прилетело и опубликовало эту надпись здесь
Не будет это лучше. От лишнего копирования-то все равно не избавитесь. А вызов метода — это не так страшно. Тем более, что никакого вызова в данном случае в скомпилированном коде нет — метод инлайнится.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
C:\Windows\Temp>java Test2 (charAt)
240098112
210

C:\Windows\Temp>java Test3 (getChars)
240098112
247

Меньше — лучше, правильно ведь? charAt выигрывает.

C:\Windows\Temp>java -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)

Вы бы еще в чистом интерпретаторе запустили и в нем сравнивали.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Мне смайлик следовало поставить во фразе про интерпретатор? :)
Тега <irony> явно не хватает.
Давайте перенесем дальнейшую дискуссию в личку, чтоб более не засорять топик.
НЛО прилетело и опубликовало эту надпись здесь
А если сравнить эти функции с кодом написанным на c и загруженным в java через JNI. Какова будет разница в производительности? Так, для сравнения…
м'сье знает толк…
«Массив b можно преобразовать обратно в строку с помощью конструктора «new String(byte[])»:»
Это вы для ASCII написало, но на самом деле:
«String(byte[] bytes) Constructs a new String by decoding the specified array of bytes using the platform's default charset.»
Т.е. это ни разу ни ASCII и на каком-нибудь Linux или в Японии вы запросто всё испортите из-за того, что входной пото байт будет рассматриваться, как последовательность UTF8.
Хуже того, некоторые символы могут преобразовываться в Char неоднозначно — управляющие символы и т.п.
Короче говоря — плохо разобрались в предмете.
Интересно, были ли тесты написаны с учетом особенностей микробенчмаркинга в Яве или нет.
НЛО прилетело и опубликовало эту надпись здесь
Извините. Возможно, вы и анализировали output компилятора и ассемблерный код. Тогда я неправ.
Я ж судил только по очевидным признакам:
— Warm-up phase нет.
— Изначально выводы были основаны на измерениях результатов клиентского компилятора.
— Предотвращение OSR не выполнено.
— Печать и инициализация классов внутри timing phase.
А ведь эти самые главные!
НЛО прилетело и опубликовало эту надпись здесь
это конечно прекрасно — оптимизировать преобразования из массивов в строки и обратно
круто, что 30%
но если подоюные вызовы занимали 5% времени выполнения запроса, то ускорение будет 1,66%
и ради этого придется писать кривые самописные методы
овчинка выделки не стоит, я щетаю
И всё же иногда приходится работать с большими объёмами текстовых данных, которые требуют подобных операций. И в таком случае описанные в статье методы действительно влияют на общую производительность.
Так как уже второй раз у вас вижу в заголовке топика «[Перевод]», то выступлю в роли КО и скажу, что так делать не надо. Для переводов существует специальный тип топиков.
>Каждый символ в Java занимает 2 байта

На собеседованиях очень люблю спрашивать, как же это так, если основная фишка UTF в том, что там переменное количество байт на символ.
>The char data type (and therefore the value that a Character object encapsulates) are based on the original Unicode specification, which defined characters as fixed-width 16-bit entities

оно? :)
>The Unicode standard has since been changed to allow for characters whose representation requires more than 16 bits.

Скорее об этом и что с этим делать.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.