История изменений

Вообще твоя подъёбка «может код уже лучше производится чем у GCC/Clang?» глупо выглядит.

Я лишь поинтересовался, у тебя какие то языковые комплексы неполноценности. У GCC/Clang на удивление плохая генерация для такой распространенной конструкции, что сразу выделяется, на фоне того как они оптимизируют и довольно сложный код. А если ты сделал сворачивание лишних jmp, то я предположил что это могло повлиять на jmp table и реально привести к более лучшему коду чем у GCC/Clang.

Я в профилировщике не вижу, чтобы это сильно влияло на производительность, соответственно это не на первом месте в очереди на реализацию.

Если таблиц много и они в горячем пути, то повлияет. Или если через них реализуется полиморфизм (enum+union) вместо создания vtable из указателей на функции. Конечно намного выгоднее сделать распределение регистров если выбирать из текущих целей, я про то что это не надуманная оптимизация.

Вообще твоя подъёбка «может код уже лучше производится чем у GCC/Clang?» глупо выглядит.

Я лишь поинтересовался, у тебя какие то языковые комплексы неполноценности. У GCC/Clang на удивление плохая генерация для такой распространенной конструкции, что сразу выделяется, на фоне того как они оптимизируют и довольно сложный код. А если ты сделал сворачивание лишних jmp, то я предположил что это могло повлиять на jmp table и реально привести к более лучшему коду чем у GCC/Clang.

Я в профилировщике не вижу, чтобы это сильно влияло на производительность, соответственно это не на первом месте в очереди на реализацию.

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

Вообще твоя подъёбка «может код уже лучше производится чем у GCC/Clang?» глупо выглядит.

Я лишь поинтересовался, у тебя какие то языковые комплексы неполноценности. У GCC/Clang на удивление плохая генерация для такой распространенной конструкции, что сразу выделяется, на фоне того как они оптимизируют и довольно сложный код. А если ты сделал сворачивание лишних jmp, то я предположил что это могло повлиять на jmp table и реально привести к более лучшему коду чем у GCC/Clang.

Я в профилировщике не вижу, чтобы это сильно влияло на производительность, соответственно это не на первом месте в очереди на реализацию.

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

Вообще твоя подъёбка «может код уже лучше производится чем у GCC/Clang?» глупо выглядит.

Я лишь поинтересовался, у тебя какие то языковые комплексы неполноценности. У GCC/Clang на удивление плохая генерация для такой распространенной конструкции, что сразу выделяется, на фоне того как они оптимизируют и довольно сложный код. А если ты сделал сворачивание лишних jmp, то я предположил что это могло повлиять на jmp table и реально привести к более лучшему коду чем у GCC/Clang.

Я в профилировщике не вижу, чтобы это сильно влияло на производительность, соответственно это не на первом месте в очереди на реализацию.

Если таблиц много и они в горячем пути, то повлияет. Или если через них реализуется полиморфизм вместо создания vtable из указателей на функции.