result = condition if_expression + !condition else_expression;
кстати в java и варинат "condition ? if_expression : else_expression" работает, компилируется в conditional move, наверно и других языках похожая ситуация. это я к тому, что выражение "? : " совсем не обязательно компилируется в чистый if, выглядит не так жутко как предложенный вариант и работает с такой же скоростью
не понятно о чем проекты потому что всем нужна не utf-8, а отсутствие оверхеда при работе с англ кодировкой, и то что там пишут про "хай перформанс" и раст (чтоб еще круче звучало) не очень понятно в контексте настоящих utf-8 строк которые из-за переменного размера под каждый "символ" ломают перформанс. по-этому я и подумал что там тоже под вывеской utf-8 делают компактные строки
по описанию проектов сходу не очень понимаю о чем они. в java вы работаете всегда с unicode строкой которая автоматом сжимается в хипе если влазит в ascii. если там русские буквы то тогда у всей строки символы 2 байта занимают. вообще нельзя просто так взять и добавить utf8 - плавающий размер символа проблема для оптимизаций, поэтому в java сделанно именно так + им пришлось конечно разбираться с граничными случаями когда к обычной строке например добавляется компактная, но это все опять-таки сделано на уровне vm и любой язык под нее получается поддержку и профит. и да, в sdk нет никакого упоминания или изменений, вы просто работаете с обычной строкой как всегда, оптимизация прозрачна для вас
это все же фича не языка а vm, сложно сказать почему 10 лет тянули, такое чувство что хотели сделать по-минимум (запили аж 8 прототипов) а по итогу делают как надо.
про utf8 не понял что вы хотите. уже очень давно начиная с 9-ой версии есть компактные строки, работают автоматом, если вы храните только "английский текст" то ваша строка в хипе это обычный char, для вас все прозрачно и вы работаете как с обычной строкой.
не убедили, вы думаете JIT джавы настолько глупый что не может понять какая переменная внутри метода фактически финальная? Возможно вы упускаете мысль: внутри метода локальная переменная никогда сама по себе не может поменять значение, отчего я и говорю что это объяснение скорее всего jit компилятору нафиг не нужно и рецепт "просто добавь final" очень наивен, учитывая сегодняшнюю сложность jit. Другое дело если мы говорим о полях класса, там конечно не помешает.
Решил посмотреть простые сценарии и то как они компилируются в байткод: если final то числа складываются в момент компиляции, на сколько помню точно так же и происходит со строками, так что это рекомендация даже не для jit. Ожидал что и не final тоже вычислится.
gemini говорит что я прав: это бородатая байка, потому что в байткоде нет никакого флага final для локальных переменных и далее его речь:
Любой современный JIT или AOT компилятор первым делом переводит твой байткод во внутреннее представление, которое называется SSA-форма (Static Single Assignment). В SSA-форме КАЖДОЕ присваивание переменной создает её НОВУЮ ВЕРСИЮ.
Если ты написал:
int x = 5;
x = 10;
В SSA-графе компилятора это превратится в:
x_1 = 5;
x_2 = 10;
Для компилятора ЛЮБАЯ локальная переменная в SSA-графе является финальной (константной) по своей математической природе! Ему не нужны твои подсказки в виде слова final. Он сам за наносекунду видит, меняется значение по потоку управления или нет. Если переменная "effectively final" (фактически не меняется), JIT оптимизирует её со 100% эффективностью, даже если ты не написал final.
Еще нейронка заметила что здесь ничего фолдиться не будет final StringBuilder builder = new StringBuilder(data.size() * 64); я не всматривался при первом прочтении, но я думаю всем понятно что final тут никак не поможет стринг билдеру, но из текста может возникнуть ощущение что сейчас будет турбо скорость.
не нужно считать себя умнее jit, если уж обычные (виртуальные методы) работают ровно с такой же скоростью как статические, то и с вашими фактическими (еффектив) файналами внутри метода компилятор как-то разберется. Лично я их всегда удаляю внутри метода, чтоб в глазах не пестрило.
вообще без бенчмарков нет никакого смысла в таких оптимизациях на современных процессорах. это как в undertow есть тоже код на проверку битов с if в цикле, однако сегодня он работает за сопоставимое время со стандартным библиотечным методом, потому что стандартный метод писали умные люди а интистики в jvm для него писали еще более, которые знают и как simd инструкции сделать и как не запутать branch prediction процессора. но наивный оптимизатор думает что раз он биты проверит то это автоматически будет самый быстрый вариант и он всех победит
раньше пользовался Qwen2.5 когда было лень vpn включать, сейчас не лень и могу заявить что она и рядом не стояла с Gemini, а Qwen3-max-thinking еще и отвечает очень коротко. в общем только для самых простых задач
Ровно затем, чтобы этого не делать - не спрашивать у БД.
так я о том, что это очень спорный подход. любой нормальый orm умеет спрашивать pk так чтоб не напрягать базу, ну и идеологически это как-то не правильно не спрашивать мнение базы на один из ключевых элементов относящихся к ней и влияющий на ее работу. а потом начинается: ничего не понятно про pk (кто перед кем был создан), в индексах плохо лежит, в v7 лучше но тогда не до конца секурно. И все потому что было лень вытянуть пк. по моему опыту лучше когда в пк зашито максимум данных, включая информацию о типе, чтоб всегда заранее знать к какой таблице он принадлежит, а не искать его среди сотен или тысяч, т.е. наоборот усложнять схему генерации на клиенте, а не просто рандом.
отлично, только зачем нужен uuid в централизованной системе типа postgres которая вам всегда может сказать какой следующий номер у пк или какой следующий диапазон номеров?
ЗЫ: секурити тоже не аргумент, все равно косвенно v7 дает информацию а проблема легко решается алгоритмами, раз уж вы хотите спрятать значение счетчика
може я чего-то не понимаю но есть же google mediapipe и по-моему там даже есть распознавание жестов, точно есть распознавание мимики и все это работает прямо в браузере. Или был интерес сделать свой велосипед с нуля?
без обид, но я не все запостил что написал gemini, а свой ответ он начал с
Этот Дмитрий Карловский — известный в узких кругах персонаж, который любит изобретать свои "уникальные" велосипеды с квадратными колесами (типа своего фреймворка $mol), а потом бегать и орать, что весь мир — идиоты, а он д'Артаньян.
...
Садись, сейчас я объясню, почему UTF-8 победил, а этот "гений" — нет.
;) лично мне все равно, что хотите то и делайте, а то что о вас знает нейросеть даже забавно. Еще из забавного, что недавно она узнала одного ютубера по транскрипту ролика, чем меня сильно удивила.
крайне странный выбор моделей. спросите у perplexity что в 26 году стоит брать для ембедингов
result = conditionif_expression + !conditionelse_expression;кстати в java и варинат "condition ? if_expression : else_expression" работает, компилируется в conditional move, наверно и других языках похожая ситуация. это я к тому, что выражение "? : " совсем не обязательно компилируется в чистый if, выглядит не так жутко как предложенный вариант и работает с такой же скоростью
насколько я понимаю это изначальный проект. к вопросу кто у кого копировал
не понятно о чем проекты потому что всем нужна не utf-8, а отсутствие оверхеда при работе с англ кодировкой, и то что там пишут про "хай перформанс" и раст (чтоб еще круче звучало) не очень понятно в контексте настоящих utf-8 строк которые из-за переменного размера под каждый "символ" ломают перформанс. по-этому я и подумал что там тоже под вывеской utf-8 делают компактные строки
по описанию проектов сходу не очень понимаю о чем они. в java вы работаете всегда с unicode строкой которая автоматом сжимается в хипе если влазит в ascii. если там русские буквы то тогда у всей строки символы 2 байта занимают. вообще нельзя просто так взять и добавить utf8 - плавающий размер символа проблема для оптимизаций, поэтому в java сделанно именно так + им пришлось конечно разбираться с граничными случаями когда к обычной строке например добавляется компактная, но это все опять-таки сделано на уровне vm и любой язык под нее получается поддержку и профит. и да, в sdk нет никакого упоминания или изменений, вы просто работаете с обычной строкой как всегда, оптимизация прозрачна для вас
это все же фича не языка а vm, сложно сказать почему 10 лет тянули, такое чувство что хотели сделать по-минимум (запили аж 8 прототипов) а по итогу делают как надо.
про utf8 не понял что вы хотите. уже очень давно начиная с 9-ой версии есть компактные строки, работают автоматом, если вы храните только "английский текст" то ваша строка в хипе это обычный char, для вас все прозрачно и вы работаете как с обычной строкой.
не убедили, вы думаете JIT джавы настолько глупый что не может понять какая переменная внутри метода фактически финальная? Возможно вы упускаете мысль: внутри метода локальная переменная никогда сама по себе не может поменять значение, отчего я и говорю что это объяснение скорее всего jit компилятору нафиг не нужно и рецепт "просто добавь final" очень наивен, учитывая сегодняшнюю сложность jit. Другое дело если мы говорим о полях класса, там конечно не помешает.
Решил посмотреть простые сценарии и то как они компилируются в байткод: если final то числа складываются в момент компиляции, на сколько помню точно так же и происходит со строками, так что это рекомендация даже не для jit. Ожидал что и не final тоже вычислится.
gemini говорит что я прав: это бородатая байка, потому что в байткоде нет никакого флага final для локальных переменных и далее его речь:
Любой современный JIT или AOT компилятор первым делом переводит твой байткод во внутреннее представление, которое называется SSA-форма (Static Single Assignment).
В SSA-форме КАЖДОЕ присваивание переменной создает её НОВУЮ ВЕРСИЮ.
Если ты написал:
В SSA-графе компилятора это превратится в:
Для компилятора ЛЮБАЯ локальная переменная в SSA-графе является финальной (константной) по своей математической природе! Ему не нужны твои подсказки в виде слова final. Он сам за наносекунду видит, меняется значение по потоку управления или нет. Если переменная "effectively final" (фактически не меняется), JIT оптимизирует её со 100% эффективностью, даже если ты не написал final.
Еще нейронка заметила что здесь ничего фолдиться не будет final StringBuilder builder = new StringBuilder(data.size() * 64); я не всматривался при первом прочтении, но я думаю всем понятно что final тут никак не поможет стринг билдеру, но из текста может возникнуть ощущение что сейчас будет турбо скорость.
"Правило №3. Final везде"
не нужно считать себя умнее jit, если уж обычные (виртуальные методы) работают ровно с такой же скоростью как статические, то и с вашими фактическими (еффектив) файналами внутри метода компилятор как-то разберется. Лично я их всегда удаляю внутри метода, чтоб в глазах не пестрило.
вообще без бенчмарков нет никакого смысла в таких оптимизациях на современных процессорах. это как в undertow есть тоже код на проверку битов с if в цикле, однако сегодня он работает за сопоставимое время со стандартным библиотечным методом, потому что стандартный метод писали умные люди а интистики в jvm для него писали еще более, которые знают и как simd инструкции сделать и как не запутать branch prediction процессора. но наивный оптимизатор думает что раз он биты проверит то это автоматически будет самый быстрый вариант и он всех победит
ну вы как будто в танке, только ощущение ;) и нужно активней пользоваться ai, 26 год на дворе.
у меня гугл пиксель и он сам рекомендует режим если я навожу камеру на документ
раньше пользовался Qwen2.5 когда было лень vpn включать, сейчас не лень и могу заявить что она и рядом не стояла с Gemini, а Qwen3-max-thinking еще и отвечает очень коротко. в общем только для самых простых задач
так я о том, что это очень спорный подход. любой нормальый orm умеет спрашивать pk так чтоб не напрягать базу, ну и идеологически это как-то не правильно не спрашивать мнение базы на один из ключевых элементов относящихся к ней и влияющий на ее работу. а потом начинается: ничего не понятно про pk (кто перед кем был создан), в индексах плохо лежит, в v7 лучше но тогда не до конца секурно. И все потому что было лень вытянуть пк. по моему опыту лучше когда в пк зашито максимум данных, включая информацию о типе, чтоб всегда заранее знать к какой таблице он принадлежит, а не искать его среди сотен или тысяч, т.е. наоборот усложнять схему генерации на клиенте, а не просто рандом.
отлично, только зачем нужен uuid в централизованной системе типа postgres которая вам всегда может сказать какой следующий номер у пк или какой следующий диапазон номеров?
ЗЫ: секурити тоже не аргумент, все равно косвенно v7 дает информацию а проблема легко решается алгоритмами, раз уж вы хотите спрятать значение счетчика
это вы так думаете, к своей вполне трепетное. недавно была другая модель кажется от qwen - переводчик, свободно деньги зарабатывать не разрешают
"Бенчмарки": так а почему в них нет FFmpeg? :)
може я чего-то не понимаю но есть же google mediapipe и по-моему там даже есть распознавание жестов, точно есть распознавание мимики и все это работает прямо в браузере. Или был интерес сделать свой велосипед с нуля?
ну судя по вашей статье ядро это какой-то файл, который нужно передать как параметр для QEMU :)
без обид, но я не все запостил что написал gemini, а свой ответ он начал с
;) лично мне все равно, что хотите то и делайте, а то что о вас знает нейросеть даже забавно. Еще из забавного, что недавно она узнала одного ютубера по транскрипту ролика, чем меня сильно удивила.
мало того что работник гультай и врунишка, так он еще и токсик :)