Gaetano Mendola <[EMAIL PROTECTED]> 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:

(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

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.


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to