signed division in hash_search_with_hash_value(ENTER) has high overhead

Поиск
Список
Период
Сортировка
От Andres Freund
Тема signed division in hash_search_with_hash_value(ENTER) has high overhead
Дата
Msg-id 20160622002607.mbsfsm42cxqomi4d@alap3.anarazel.de
обсуждение исходный текст
Список pgsql-hackers
Hi,

During several profile runs I've seen the division inif (action == HASH_ENTER || action == HASH_ENTER_NULL){    /*
*Can't split if running in partitioned mode, nor if frozen, nor if     * table is the subject of any active
hash_seq_searchscans.  Strange     * order of these tests is to try to check cheaper conditions first.     */    if
(!IS_PARTITIONED(hctl)&& !hashp->frozen &&        hctl->freeList[0].nentries / (long) (hctl->max_bucket + 1) >=
hctl->ffactor&&        !has_seq_scans(hashp))        (void) expand_table(hashp);}
 
taking up significant amounts of time.  Which is not particularly
surprising: A signed 64 integer division (which is what we're dealing
with here) takes up to ~100 cycles, is microcoded, and prevents
instruction level parallelism.

We could cast to unsigned long - which would be faster - but it seems
like it'd be better to compute a threshold in
init_htab()/expand_table(), and make that && hctl->freeList[0].nentries >= hctl.next_expansion
or somesuch.

I don't plan to do that, but I wanted to document it, should somebody
else be motivated to look into this.

Greetings,

Andres Freund



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Speaking of breaking compatibility...standard_conforming_strings
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Missing checks when malloc returns NULL...