Thread: Optimizing Node Files Support

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], 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

diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index f2568ff5e6..1a8df587ce 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -27,8 +27,9 @@
  */

 /* Copy a simple scalar field (int, float, bool, enum, etc) */
+/* We now assume that scalar fields are flat-copied via initial memcpy */
 #define COPY_SCALAR_FIELD(fldname) \
-    (newnode->fldname = from->fldname)
+    ((void) 0)

 /* Copy a field that is a pointer to some kind of Node or Node tree */
 #define COPY_NODE_FIELD(fldname) \
@@ -43,8 +44,9 @@
     (newnode->fldname = from->fldname ? pstrdup(from->fldname) : (char *) NULL)

 /* Copy a field that is an inline array */
+/* These too should be taken care of by initial memcpy */
 #define COPY_ARRAY_FIELD(fldname) \
-    memcpy(newnode->fldname, from->fldname, sizeof(newnode->fldname))
+    ((void) 0)

 /* Copy a field that is a pointer to a simple palloc'd object of size sz */
 #define COPY_POINTER_FIELD(fldname, sz) \
@@ -59,7 +61,7 @@

 /* Copy a parse location field (for Copy, this is same as scalar case) */
 #define COPY_LOCATION_FIELD(fldname) \
-    (newnode->fldname = from->fldname)
+    ((void) 0)


 #include "copyfuncs.funcs.c"
@@ -72,8 +74,9 @@
 static Const *
 _copyConst(const Const *from)
 {
-    Const       *newnode = makeNode(Const);
+    Const       *newnode = palloc_object(Const);

+    memcpy(newnode, from, sizeof(Const));
     COPY_SCALAR_FIELD(consttype);
     COPY_SCALAR_FIELD(consttypmod);
     COPY_SCALAR_FIELD(constcollid);
@@ -107,8 +110,9 @@ _copyConst(const Const *from)
 static A_Const *
 _copyA_Const(const A_Const *from)
 {
-    A_Const    *newnode = makeNode(A_Const);
+    A_Const    *newnode = palloc_object(A_Const);

+    memcpy(newnode, from, sizeof(A_Const));
     COPY_SCALAR_FIELD(isnull);
     if (!from->isnull)
     {
@@ -150,8 +154,10 @@ _copyExtensibleNode(const ExtensibleNode *from)
     const ExtensibleNodeMethods *methods;

     methods = GetExtensibleNodeMethods(from->extnodename, false);
-    newnode = (ExtensibleNode *) newNode(methods->node_size,
-                                         T_ExtensibleNode);
+
+    newnode = (ExtensibleNode *) palloc(methods->node_size);
+    memcpy(newnode, from, methods->node_size);
+
     COPY_STRING_FIELD(extnodename);

     /* copy the private fields */
diff --git a/src/backend/nodes/gen_node_support.pl b/src/backend/nodes/gen_node_support.pl
index b3c1ead496..4f62fa09cb 100644
--- a/src/backend/nodes/gen_node_support.pl
+++ b/src/backend/nodes/gen_node_support.pl
@@ -671,8 +671,9 @@ foreach my $n (@node_types)
 static $n *
 _copy${n}(const $n *from)
 {
-\t${n} *newnode = makeNode($n);
+\t${n} *newnode = palloc_object($n);

+\tmemcpy(newnode, from, sizeof($n));
 " unless $struct_no_copy;

     print $eff "

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