Hi Tom ,Matthias
Thank you for your explanation.Maybe future compilers will be able to
do intelligent prediction?
Thanks
Tom Lane <t...@sss.pgh.pa.us> 于2024年6月30日周日 23:23写道：
> Matthias van de Meent <boekewurm+postg...@gmail.com> writes:
> > On Sun, 30 Jun 2024, 15:56 wenhui qiu, <qiuwenhu...@gmail.com> wrote:
> >> if (unlikely(ExecutorRun_hook)),
>
> > While hooks are generally not installed by default, I would advise
> > against marking the hooks as unlikely, as that would unfairly penalize
> > the performance of extensions that do utilise this hook (or hooks in
> > general when applied to all hooks).
>
> In general, we have a policy of using likely/unlikely very sparingly,
> and only in demonstrably hot code paths. This hook call certainly
> doesn't qualify as hot.
>
> Having said that ... something I've been wondering about is how to
> teach the compiler that error paths are unlikely. Doing this
> across-the-board wouldn't be "sparingly", but I think surely it'd
> result in better code quality on average. This'd be easy enough
> to do in Assert:
>
> #define Assert(condition) \
> do { \
> - if (!(condition)) \
> + if (unlikely(!(condition))) \
> ExceptionalCondition(#condition, __FILE__,
> __LINE__); \
> } while (0)
>
> but on the other hand we don't care that much about micro-optimization
> of assert-enabled builds, so maybe that's not worth the trouble. The
> real win would be if constructs like
>
> if (trouble)
> ereport(ERROR, ...);
>
> could be interpreted as
>
> if (unlikely(trouble))
> ereport(ERROR, ...);
>
> But I surely don't want to make thousands of such changes manually.
> And it's possible that smart compilers already realize this, using
> a heuristic that any path that ends in pg_unreachable() must be
> unlikely. Is there a way to encourage compilers to believe that?
>
> regards, tom lane
>
