From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] Small optimization across postgres (remove strlen duplicate usage) |
Date: | 2020-04-19 23:23:03 |
Message-ID: | CAEudQApTrxtDtF5BkhikFXimY9Fk6zgKeqaeGgjoJNEsiH5a7A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Em dom., 19 de abr. de 2020 às 19:00, David Rowley <dgrowleyml(at)gmail(dot)com>
escreveu:
> On Mon, 20 Apr 2020 at 09:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > The cases where Ranier proposes to replace strlen(foo) == 0
> > with a test on foo[0] do seem like wins, though. Asking for
> > the full string length to be computed is more computation than
> > necessary, and it's less clear that the compiler could be
> > expected to save you from that. Anyway there's a coding style
> > proposition that we should be doing this consistently, and
> > certainly lots of places do do this without using strlen().
>
> Looking at https://godbolt.org/z/6XsjbA it seems like GCC is pretty
> good at getting rid of the strlen call even at -O0. It takes -O1 for
> clang to use it and -O2 for icc.
>
I tried: https://godbolt.org with:
-O2:
f1:
int main (int argv, char **argc)
{
return strlen(argc[0]) == 0;
}
f1: Assembly
main: # @main
mov rcx, qword ptr [rsi]
xor eax, eax
cmp byte ptr [rcx], 0
sete al
ret
f2:
int main (int argv, char **argc)
{
return argc[0] == '\0';
}
f2: Assembly
main: # @main
xor eax, eax
cmp qword ptr [rsi], 0
sete al
ret
For me clearly str [0] == '\ 0', wins.
regards,
Ranier Vilela
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2020-04-19 23:36:26 | Re: [PATCH] Small optimization across postgres (remove strlen duplicate usage) |
Previous Message | Peter Geoghegan | 2020-04-19 23:19:29 | Re: v13: Performance regression related to FORTIFY_SOURCE |