Optimizing Node Files Support

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.

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.

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.

5. Avoid useless attribution, ignoring the result of pg_strtok when it is

unnecessary.

Looks worse.

--
John Naylor
EDB: http://www.enterprisedb.com

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

On Fri, 2 Dec 2022 at 19:06, Ranier Vilela <ranier.vf@gmail.com> wrote:

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.

The patch does not apply on top of HEAD as in [1]http://cfbot.cputube.org/patch_41_4034.log, please post a rebased patch:
=== Applying patches on top of PostgreSQL commit ID
e351f85418313e97c203c73181757a007dfda6d0 ===
=== applying patch ./v1-optimize_gen_nodes_support.patch
patching file src/backend/nodes/gen_node_support.pl
Hunk #2 succeeded at 680 with fuzz 2.
Hunk #3 FAILED at 709.
...
Hunk #7 succeeded at 844 (offset 42 lines).
1 out of 7 hunks FAILED -- saving rejects to file
src/backend/nodes/gen_node_support.pl.rej

[1]: http://cfbot.cputube.org/patch_41_4034.log

Regards,
Vignesh

vignesh C <vignesh21@gmail.com> writes:

The patch does not apply on top of HEAD as in [1], please post a rebased patch:

Yeah. The way that I'd been thinking of optimizing the copy functions
was more or less as attached: continue to write all the COPY_SCALAR_FIELD
macro calls, but just make them expand to no-ops after an initial memcpy
of the whole node. This preserves flexibility to do something else while
still getting the benefit of substituting memcpy for retail field copies.
Having said that, I'm not very sure it's worth doing, because I do not
see any major reduction in code size:

HEAD:
text data bss dec hex filename
53601 0 0 53601 d161 copyfuncs.o
w/patch:
text data bss dec hex filename
49850 0 0 49850 c2ba copyfuncs.o

I've not looked at the generated assembly code, but I suspect that
my compiler is converting the memcpy's into inlined code that's
hardly any smaller than field-by-field assignment. Also, it's
rather debatable that it'd be faster, especially for node types
that are mostly pointer fields, where the memcpy is going to be
largely wasted effort.

I tend to agree with John that the rest of the changes proposed
in the v1 patch are not useful improvements, especially with
no evidence offered that they'd make the code smaller or faster.

regards, tom lane

Em qua., 4 de jan. de 2023 às 19:39, Tom Lane <tgl@sss.pgh.pa.us> escreveu:

vignesh C <vignesh21@gmail.com> writes:

The patch does not apply on top of HEAD as in [1], please post a rebased

patch:

Yeah. The way that I'd been thinking of optimizing the copy functions
was more or less as attached: continue to write all the COPY_SCALAR_FIELD
macro calls, but just make them expand to no-ops after an initial memcpy
of the whole node. This preserves flexibility to do something else while
still getting the benefit of substituting memcpy for retail field copies.
Having said that, I'm not very sure it's worth doing, because I do not
see any major reduction in code size:

I think this option is worse.
By disabling these macros, you lose their use in other areas.
By putting more intelligence into gen_node_support.pl, to either use memcpy
or the macros is better, IMO.
In cases of one or two macros, would it be faster than memset?

HEAD:
text data bss dec hex filename
53601 0 0 53601 d161 copyfuncs.o
w/patch:
text data bss dec hex filename
49850 0 0 49850 c2ba copyfuncs.o

I haven't tested it on Linux, but on Windows, there is a significant
reduction.

head:
8,114,688 postgres.exe
121.281 copyfuncs.funcs.c

patched:
8,108,544 postgres.exe
95.321 copyfuncs.funcs.c

I've not looked at the generated assembly code, but I suspect that
my compiler is converting the memcpy's into inlined code that's
hardly any smaller than field-by-field assignment. Also, it's
rather debatable that it'd be faster, especially for node types
that are mostly pointer fields, where the memcpy is going to be
largely wasted effort.

IMO, with many field assignments, memcpy would be more faster.

I tend to agree with John that the rest of the changes proposed
in the v1 patch are not useful improvements, especially with
no evidence offered that they'd make the code smaller or faster.

I tried using palloc_object, as you proposed, but several tests failed.
So I suspect that some fields are not filled in correctly.
It would be an advantage to avoid memset in the allocation (palloc0), but I
chose to keep it because of the errors.

This way, if we use palloc0, there is no need to set NULL on
COPY_STRING_FIELD.

Regarding COPY_POINTER_FIELD, it is wasteful to cast size_t to size_t.

v3 attached.

regards,
Ranier Vilela

Ranier Vilela <ranier.vf@gmail.com> writes:

Em qua., 4 de jan. de 2023 às 19:39, Tom Lane <tgl@sss.pgh.pa.us> escreveu:

Yeah. The way that I'd been thinking of optimizing the copy functions
was more or less as attached: continue to write all the COPY_SCALAR_FIELD
macro calls, but just make them expand to no-ops after an initial memcpy
of the whole node.

I think this option is worse.
By disabling these macros, you lose their use in other areas.

What other areas? They're local to copyfuncs.c.

The bigger picture here is that as long as we have any manually-maintained
node copy functions, it seems best to adhere to the existing convention
of explicitly listing each and every field in them. I'm far more
concerned about errors-of-omission than I am about incremental performance
gains (which still haven't been demonstrated to exist, anyway).

v3 attached.

I think you're wasting people's time if you don't provide some
performance measurements showing that this is worth doing from
a speed standpoint.

regards, tom lane

I think it's clear we aren't going to be taking this patch in its
current form. Perhaps there are better ways to do what these files do
(I sure think there are!) but I don't think microoptimizing the
copying is something people are super excited about. It sounds like
rethinking how to make these functions more convenient for programmers
to maintain reliably would be more valuable.

I guess I'll mark it Returned with Feedback -- if there are
significant performance gains to show without making the code harder
to maintain and/or a nicer way to structure this code in general then
we can revisit this.

--
Gregory Stark
As Commitfest Manager