Я уверен что алокации в конструкторе по умолчанию замедлят код сильно больше ифа в пушбеке

Не совсем, конечно. Во первых, в конструкторе у тебя выделяется скажем 4 элемента, внутри аллокатора, это часто будет задействован внутренний пул, что вообще ни о чем + ты используешь эту память после, в ином случае, в конструкторе ты ну лишь указатели, что тоже свое немного, но забирает

Не совсем, конечно. Во первых, в конструкторе у тебя выделяется скажем 4 элемента, внутри аллокатора, это часто будет задействован внутренний пул, что вообще ни о чем + ты используешь эту память после, в ином случае, в конструкторе ты ну лишь указатели, что тоже свое немного, но забирает

Это всеравно больше одного ифа

да, но он вызовется один раз, а вот p_b вызывается чаще.

Там же иф только на рост

ты слышал про polymorphic memory resource? (оффтоп слегка)

Или, стандарт запрещает резервировать память в умолчательном конструкторе?

Я так понимаю, по итогу, не имея возможности заранее задавать буффер, мы получаем деградацию перфоманса, пусть и маленькую: когда начальный размер нуль, в push_back мы должны будем сделать проверку и выставить нужный размер - если нуль, то скажем, 4 элемента, а если не нуль, то умножим на два, как и делает gcc...Но это лишняя инструкция, в лучшем случае - cmove, если мы про x86, в худшем - ветка, наверное. Или такой гарантии нету и все же мы можем дёрнуть аллокатор в конструкторе вектора, при этом как то порешав проблемы с noexcept spec?(которая по утверждению cppref берется с Умолчательного ctor allocator, а не у функции allocate!!!)

Или, стандарт запрещает резервировать память в умолчательном конструкторе?

Какая деградация, push_back в любом случае делает проверку capacity, независимо от того был reserve или нет.