Comments 12
Метод java.lang.String::equals интринзифицирован, поэтому познакового сравнения при исполнении не происходит.
А в чем неточность-то? Или JIT сравнивает строки не точно так же познаково, пусть и более быстро?
Я думал, что исполняться будет ява-кода из `String::equals`, но интринзифицированный метод, насколько я понимаю, исполняет нативный код, оптимизированный под конкретную платформу.
Тем не менее, оптимизация тут всего лишь означает уменьшение константы. Магии не бывает, и сравнить две строки без побайтового либо посимвольного прохода по ним невозможно.
Там векторизуется неплохо для длинных строк, но всё равно, конечно О(N). Начиная с Java 9, кстати, есть интересный частный случай: если в одной строке все символы Latin1, а в другой — нет, то сразу скажет, что не равны.
сравнить две строки без побайтового либо посимвольного прохода по ним невозможно.
Можно. Посмотрите на String::intern.
Вполне можно добиться того, что в куче не будет одинаковых строк. Т.е., если в разных местах в коде использовать одинаковое строковое значение, то оно будет указывать на один и тот же объект.
Я не знаю, насколько это поведение надежно, но данные оптимизации действительно имеют место быть при компиляции. Хотя я лично на них не полагаюсь, и пишу в коде string1.equals(string2) вместо string1 == string2. Но второй вариант тоже, в теории, будет работать достаточно стабильно.
Метод String::intern не вызывается автоматически для всех конструируемых строк, а оптимизации при компиляции применяются только к строковым литералам.
Так что второй вариант является ошибкой, и не должен работать ни в теории, ни на практике. Вот пример: https://ideone.com/c0OYGW
Можно. Посмотрите на String::intern.
Не надо пользоваться String::intern! С восклицательным знаком не надо. Хотите снизить потребление памяти строками в какой-то операции — складывайте строки в Map, и оттуда же забирайте.
Жалко, что больше не статей, кроме вашей. По крайне мере я не нашел, только презентации, или YT видео.
Есть крутые доклады Шипилёва и Куксенко, они об общих началах улучшений производительности и о низкоуровневых вещах. Универсальную статью написать сложно, т. к. примеры из этой статьи, основаны на нашем конкретном проекте и совсем не обязательно подойдут для вашего. Как мне кажется, именно поэтому тот же Шипилёв, Черёмин или Вакарт в основном рассказывают об улучшениях кода, привязанного только к JDK как к некой постоянной для многих разработчиков.
Я не про это говорил. Не о применимости докладов, а о том, что если были бы текстовые версии докладов, было бы лучше.
JUGRu десятками публикует расшифровки докладов с конференций
habr.com/company/jugru/blog Только там рыться надо, потому что они тонну всего помимо этого публикуют. Вот, например, из недавнего habr.com/company/jugru/blog/424763
habr.com/company/jugru/blog Только там рыться надо, потому что они тонну всего помимо этого публикуют. Вот, например, из недавнего habr.com/company/jugru/blog/424763
Sign up to leave a comment.
Загубить производительность