Re: equal() perf tweak

Gaetano Mendola <mendola(at)bigfoot(dot)com> writes:
> An interesting think that stl::list do is to never do
> an "if" branch during an insert/remove phase

Why is this significant? Surely you're not claiming that avoid the
branch will affect performance in a meaningful way...

> What if you will never call the size() on a list doing massive
> insert?

Then you do a few extra integer increments. Compared to, say, a
palloc() for each new list node, I'm skeptical those increments will
significantly affect performance.

> May be we need two list, depending on the way we are going to use
> it?

You mean one in which we keep track of the length, and another in
which we don't? That seems like a lot of pain for a very little gain.

> I'm too much C++ oriented and another very weak argument is: for the
> same reason that STL (at least in gcc) doesn't have it:
> http://gcc.gnu.org/ml/gcc-bugs/1998-12/msg00270.html

(1) Not relevant to us

(2) An additional word per List is hardly a prohibitive amount of
overhead, as we don't create an obscene number of Lists (saving a
word per ListCell would be a different matter).

(3) STL needs to be a general-purpose library, while we only need to
worry about what the requirements of the backend: passing around
and manually incrementing list lengths would be horribly painful.

My intuition/judgement is that we call length() often enough in the
backend that it is worth keeping track of the list length:

$ grep -rI ' length(' src/backend/* | grep -v Assert | \
grep -v '\.sh' | grep -v '/\*' | wc -l
139

But I'm not adamant about it. That said, I'm unconvinced by the
arguments for removing the list length I've heard so far.

BTW, thanks for the feedback, Tom and Gaetano.

-Neil