Re: Optimizing Node Files Support
| От | Ranier Vilela |
|---|---|
| Тема | Re: Optimizing Node Files Support |
| Дата | |
| Msg-id | CAEudQAp0fDc_3ps0F-NAnmOUpH_r08uwYx0YZigi9=cXp72Eww@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Optimizing Node Files Support (John Naylor <john.naylor@enterprisedb.com>) |
| Ответы |
Re: Optimizing Node Files Support
|
| Список | pgsql-hackers |
Hi, thanks for reviewing this.
Em sex., 2 de dez. de 2022 às 09:24, John Naylor <john.naylor@enterprisedb.com> escreveu:
On Thu, Dec 1, 2022 at 8:02 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
>
> Hi,
>
> I believe that has room for improving generation node files.
>
> The patch attached reduced the size of generated files by 27 kbytes.
> From 891 kbytes to 864 kbytes.
>
> About the patch:
> 1. Avoid useless attribution when from->field is NULL, once that
> the new node is palloc0.
>
> 2. Avoid useless declaration variable Size, when it is unnecessary.
Not useless -- it prevents a multiple evaluation hazard, which this patch introduces.
It's doubting, that patch introduces some hazard here.
But I think that casting size_t (typedef Size) to size_t is worse and is unnecessary.
Adjusted in the v1 patch.
> 3. Optimize comparison functions like memcmp and strcmp, using
> a short-cut comparison of the first element.
Not sure if the juice is worth the squeeze. Profiling would tell.
This is a cheaper test and IMO can really optimize, avoiding a function call.
> 4. Switch several copy attributions like COPY_SCALAR_FIELD or COPY_LOCATION_FIELD
> by one memcpy call.
My first thought is, it would cause code churn.
It's a weak argument.
Reduced 27k from source code, really worth it.
> 5. Avoid useless attribution, ignoring the result of pg_strtok when it is unnecessary.
Looks worse.
Better to inform the compiler that we really don't need the result.
regards,
Ranier Vilela
Вложения
В списке pgsql-hackers по дате отправления: