Re: equal() perf tweak

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: equal() perf tweak
Дата
Msg-id 1067878074.3089.348.camel@tokyo
обсуждение исходный текст
Ответ на Re: equal() perf tweak  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: equal() perf tweak  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-patches
On Mon, 2003-11-03 at 10:04, Tom Lane wrote:
> You have effectively reverted the code to its previous slow state.

Erm, the original version of this code in CVS (from ~7 years ago) is the
following:

    case T_List:
    {
        List *la = (List*)a;
        List *lb = (List*)b;
        List *l;

        if (a==NULL && b==NULL)
        return (true);
        if (length(a)!=length(b))
        return (false);
        foreach(l, la) {
        if (!equal(lfirst(l), lfirst(lb)))
            return (false);
        lb = lnext(lb);
        }
        retval = true;
    }
    break;

i.e. it is effectively the same as the code in CVS HEAD. To what
"previous state" does this patch revert the code?

> The problem with what you've done is that it recursively applies equal()
> to the list contents, which may take a very large number of cycles, only
> to eventually fail because one list is a prefix of the other.  The point
> of the current coding is to detect that condition before we recurse.

I don't understand: granted, this applies equal() to each element of the
list, but why would that be particularly slow?

equal() applied to the lfirst() of a list doesn't invoke equal() on a
T_List node (the tag of the lfirst() of the list is the data type of the
elements of the list), so there should only be a single level of
recursion.

I was going to benchmark this, but pulling the list code out of the rest
of the source is a bit hairy. Let me know if you think this would be
helpful.

-Neil



В списке pgsql-patches по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: equal() perf tweak
Следующее
От: Neil Conway
Дата:
Сообщение: Re: bufmgr code cleanup