[Перевод] Java Best Practices. Преобразование Char в Byte и обратно

[VenomBlood]

Наши собственные методы добились 15% увеличения количества операций в секунду по сравнению с «new String(byte[])» и 30% увеличения количества операций в секунду по сравнению с «bytesToStringUTFNIO(byte[])».

В итоге, наши методы добились в общем 45% ускорения

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

А то получается изначальный автор таким хитрым софизмом более чем в два раза увеличил процентные показатели эффективности своего метода.

[ahriman]

Справедливости ради надо уточнить, что местами статья действительно вызывает какие-то сомнения. Однако то, что выигрыш есть, несомненно — лично померял.

[apangin]

Неправильно подозреваете. Одинаково работают. Можете проверить.
Совсем недавно я приводил пример, когда метод в три раза длиннее по байткоду компилируется один-в-один, как и короткий метод.

[apangin]

А можно еще ускорить процентов этак на 50, если избавиться от str.toCharArray(); и пользоваться str.charAt().

[apangin]

Потому что проверял и знаю.
А еще это вполне логично даже из общих соображений: toCharArray() создает новый массив, увеличивая нагрузку на память и копируя символы лишний раз, в то время как charAt() достает символ непосредственно из строки.

[apangin]

Не будет это лучше. От лишнего копирования-то все равно не избавитесь. А вызов метода — это не так страшно. Тем более, что никакого вызова в данном случае в скомпилированном коде нет — метод инлайнится.

[apangin]

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)

Вы бы еще в чистом интерпретаторе запустили и в нем сравнивали.

[apangin]

Мне смайлик следовало поставить во фразе про интерпретатор? :)
Тега <irony> явно не хватает.
Давайте перенесем дальнейшую дискуссию в личку, чтоб более не засорять топик.

[VaiMR]

А если сравнить эти функции с кодом написанным на c и загруженным в java через JNI. Какова будет разница в производительности? Так, для сравнения…

[Vanger13]

м'сье знает толк…

[Sap_ru]

«Массив 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 неоднозначно — управляющие символы и т.п.
Короче говоря — плохо разобрались в предмете.

[WhitePigeon]

Интересно, были ли тесты написаны с учетом особенностей микробенчмаркинга в Яве или нет.

[apangin]

Чертовски правильный вопрос!
Например, в выложенных здесь javatest.zip и javatest2.zip нарушены практически все пункты правил написания микробенчмарков для JVM.

[apangin]

Извините. Возможно, вы и анализировали output компилятора и ассемблерный код. Тогда я неправ.
Я ж судил только по очевидным признакам:
— Warm-up phase нет.
— Изначально выводы были основаны на измерениях результатов клиентского компилятора.
— Предотвращение OSR не выполнено.
— Печать и инициализация классов внутри timing phase.
А ведь эти самые главные!

[stas_agarkov]

это конечно прекрасно — оптимизировать преобразования из массивов в строки и обратно
круто, что 30%
но если подоюные вызовы занимали 5% времени выполнения запроса, то ускорение будет 1,66%
и ради этого придется писать кривые самописные методы
овчинка выделки не стоит, я щетаю

[zer0access]

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

[putnik]

Так как уже второй раз у вас вижу в заголовке топика «[Перевод]», то выступлю в роли КО и скажу, что так делать не надо. Для переводов существует специальный тип топиков.

[srez]

>Каждый символ в Java занимает 2 байта

На собеседованиях очень люблю спрашивать, как же это так, если основная фишка UTF в том, что там переменное количество байт на символ.

[corristo]

>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

оно? :)

[srez]

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

Скорее об этом и что с этим делать.