Thread: 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
firstrequest...
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
"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).
regards, tom lane
"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, Pennsylvania19073
"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 somethinglike that I hope I was clear enough Regards Gaetano Mendola