Dllist public/private part
I'm improving the Dllist in these direction:
1) Avoid "if" statements in insertion/remove phase, for instance now the
AddHeader appear like this:
void
DLAddHead(Dllist *l, Dlelem *e)
{
Dlelem *where = l->dll_master_node->dle_next;
e->dle_next = where;
e->dle_prev = where->dle_prev;
where->dle_prev->dle_next = e;
where->dle_prev = e;
e->dle_list = l;
}
2) Not using a malloc but using a "special" malloc that not perform
a malloc for each request but do a BIG malloc at first request...
In the file dllist.h is not clear what is the public part and the private
part
of the implementation in particulary I see that somewhere in the code
there is the assumption that an Empty dllist is "zeroed" instead of
use DLInitList, for example this is the way to initialize a struct that
contain a Dllist itself:
cp = (CatCache *) palloc0(sizeof(CatCache) + NCCBUCKETS * sizeof(Dllist));
this break my optimization because in my implementation a
dllist is
typedef struct Dllist
{
Dlelem *dll_master_node;
} Dllist;
and not anymore:
typedef struct Dllist
{
Dlelem *dll_head;
Dlelem *dll_tail;
} Dllist;
and is empty if list->dll_master_node->dle_next and
list->master_node->dle_prev are pointing to
list->master_node ( previously allocated in DLInitList).
What should I do ? Forget the point 1) ?
Regards
Gaetano Mendola
"Tom Lane" <tgl@sss.pgh.pa.us> wrote:
"Mendola Gaetano" <mendola@bigfoot.com> writes:
I'm improving the Dllist in these direction:
AFAIR, catcache.c is the *only* remaining backend customer for Dllist,
and so any improvement for Dllist that breaks catcache is hardly an
improvement, no?1) Avoid "if" statements in insertion/remove phase, for instance now the
AddHeader appear like this:<shrug> ... unless you can convert DLAddHead into a inline macro,
I doubt there'll be any visible performance difference.2) Not using a malloc but using a "special" malloc that not perform
a malloc for each request but do a BIG malloc at first request...It would make more sense to migrate Dllist to use palloc. That's not
compatible with its use in frontend libpq; I've been speculating about
splitting off libpq to have a separate implementation instead of trying
to share code. I believe libpq only uses Dllist for the
pending-notify-events list, for which the code is poorly optimized
anyway (we don't need a doubly-linked list for that).
This mean that is waste of time work on dllist.
I seen that exist a TODO list about "features",
exist a list about: "code to optimize" ?
Regards
Gaetano Mendola
Mendola Gaetano wrote:
"Tom Lane" <tgl@sss.pgh.pa.us> wrote:
"Mendola Gaetano" <mendola@bigfoot.com> writes:
I'm improving the Dllist in these direction:
AFAIR, catcache.c is the *only* remaining backend customer for Dllist,
and so any improvement for Dllist that breaks catcache is hardly an
improvement, no?1) Avoid "if" statements in insertion/remove phase, for instance now the
AddHeader appear like this:<shrug> ... unless you can convert DLAddHead into a inline macro,
I doubt there'll be any visible performance difference.2) Not using a malloc but using a "special" malloc that not perform
a malloc for each request but do a BIG malloc at first request...It would make more sense to migrate Dllist to use palloc. That's not
compatible with its use in frontend libpq; I've been speculating about
splitting off libpq to have a separate implementation instead of trying
to share code. I believe libpq only uses Dllist for the
pending-notify-events list, for which the code is poorly optimized
anyway (we don't need a doubly-linked list for that).
I certainly would like to see Dllist removed too.
This mean that is waste of time work on dllist.
I seen that exist a TODO list about "features",
exist a list about: "code to optimize" ?
What TODO item where you looking at?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073"Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
Mendola Gaetano wrote:
I certainly would like to see Dllist removed too.This mean that is waste of time work on dllist.
I seen that exist a TODO list about "features",
exist a list about: "code to optimize" ?What TODO item where you looking at?
I see the http://developer.postgresql.org/todo.php
and for someone that want start to code is really
hard reading for example:
. Cache last known per-tuple offsets to speed long tuple access
what can do a "postgres source beginner" after reading that
sentence ?
May be is more usefull if a very "postgres source" expert, like
Bruce Momjian or Tom Lane, will compile a more detailed list
about what to do like:
We need a really efficient double linked list with this
interface blah blah blah or something like that
I hope I was clear enough
Regards
Gaetano Mendola