Комментарии 35
НЛО прилетело и опубликовало эту надпись здесь
Наши собственные методы добились 15% увеличения количества операций в секунду по сравнению с «new String(byte[])» и 30% увеличения количества операций в секунду по сравнению с «bytesToStringUTFNIO(byte[])».
В итоге, наши методы добились в общем 45% ускоренияОткуда здесь 45%?
Во первых сначала говорится про увеличение на 15% и 30% кол-ва операций в секунду (а это 13% и 23% прироста скорости обработки соответственно), а потом сразу переход на ускорение.
Во вторых в лучшем случае прирост производительности не может быть больше чем 23%, а если используются оба метода — то и того меньше.
А то получается изначальный автор таким хитрым софизмом более чем в два раза увеличил процентные показатели эффективности своего метода.
Справедливости ради надо уточнить, что местами статья действительно вызывает какие-то сомнения. Однако то, что выигрыш есть, несомненно — лично померял.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Неправильно подозреваете. Одинаково работают. Можете проверить.
Совсем недавно я приводил пример, когда метод в три раза длиннее по байткоду компилируется один-в-один, как и короткий метод.
Совсем недавно я приводил пример, когда метод в три раза длиннее по байткоду компилируется один-в-один, как и короткий метод.
А можно еще ускорить процентов этак на 50, если избавиться от str.toCharArray(); и пользоваться str.charAt().
НЛО прилетело и опубликовало эту надпись здесь
Потому что проверял и знаю.
А еще это вполне логично даже из общих соображений: toCharArray() создает новый массив, увеличивая нагрузку на память и копируя символы лишний раз, в то время как 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)
Вы бы еще в чистом интерпретаторе запустили и в нем сравнивали.
А если сравнить эти функции с кодом написанным на 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 неоднозначно — управляющие символы и т.п.
Короче говоря — плохо разобрались в предмете.
Это вы для 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 неоднозначно — управляющие символы и т.п.
Короче говоря — плохо разобрались в предмете.
Интересно, были ли тесты написаны с учетом особенностей микробенчмаркинга в Яве или нет.
Чертовски правильный вопрос!
Например, в выложенных здесь javatest.zip и javatest2.zip нарушены практически все пункты правил написания микробенчмарков для JVM.
Например, в выложенных здесь javatest.zip и javatest2.zip нарушены практически все пункты правил написания микробенчмарков для JVM.
НЛО прилетело и опубликовало эту надпись здесь
Извините. Возможно, вы и анализировали output компилятора и ассемблерный код. Тогда я неправ.
Я ж судил только по очевидным признакам:
— Warm-up phase нет.
— Изначально выводы были основаны на измерениях результатов клиентского компилятора.
— Предотвращение OSR не выполнено.
— Печать и инициализация классов внутри timing phase.
А ведь эти самые главные!
Я ж судил только по очевидным признакам:
— Warm-up phase нет.
— Изначально выводы были основаны на измерениях результатов клиентского компилятора.
— Предотвращение OSR не выполнено.
— Печать и инициализация классов внутри timing phase.
А ведь эти самые главные!
это конечно прекрасно — оптимизировать преобразования из массивов в строки и обратно
круто, что 30%
но если подоюные вызовы занимали 5% времени выполнения запроса, то ускорение будет 1,66%
и ради этого придется писать кривые самописные методы
овчинка выделки не стоит, я щетаю
круто, что 30%
но если подоюные вызовы занимали 5% времени выполнения запроса, то ускорение будет 1,66%
и ради этого придется писать кривые самописные методы
овчинка выделки не стоит, я щетаю
Так как уже второй раз у вас вижу в заголовке топика «[Перевод]», то выступлю в роли КО и скажу, что так делать не надо. Для переводов существует специальный тип топиков.
>Каждый символ в Java занимает 2 байта
На собеседованиях очень люблю спрашивать, как же это так, если основная фишка UTF в том, что там переменное количество байт на символ.
На собеседованиях очень люблю спрашивать, как же это так, если основная фишка UTF в том, что там переменное количество байт на символ.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
[Перевод] Java Best Practices. Преобразование Char в Byte и обратно