Re: patch: tsearch - some memory diet

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: patch: tsearch - some memory diet
Дата
Msg-id AANLkTikrnFO1vCn=Go4pC+F5QPLZZLUCygjNpesH7aBq@mail.gmail.com
обсуждение исходный текст
Ответ на Re: patch: tsearch - some memory diet  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
2010/9/7 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>:
> On 07/09/10 19:27, Teodor Sigaev wrote:
>>>
>>> on 32bit from 27MB (3399 blocks) to 13MB (1564 blocks)
>>> on 64bit from 55MB to cca 27MB.
>>
>> Good results. But, I think, there are more places in ispell to use
>> hold_memory():
>> - affixes and affix tree
>> - regis (REGex for ISpell, regis.c)
>
> A more general solution would be to have a new MemoryContext implementation
> that does the same your patch does. Ie. instead of tracking each allocation,
> just allocate a big chunk, and have palloc() return the next n free bytes
> from it, like a stack. pfree() would obviously not work, but wholesale
> MemoryContextDelete of the whole memory context would.
>
> I remember I actually tried this years ago, trying to reduce the overhead of
> parsing IIRC. The parser also does a lot of small allocations that are not
> individually pfree'd. And I think it helped a tiny bit, but I didn't pursue
> it further. But if there's many places where it would help, then it might
> well be worth it.

I sent patch last year - simpleAllocator, and this idea was rejected.
But now I dislike this idea too. This is unclear, and some forgotten
"free" calling can do problems. This is more simple, more readable and
secure.

Regards

Pavel Stehule

>
> --
>  Heikki Linnakangas
>  EnterpriseDB   http://www.enterprisedb.com
>


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

Предыдущее
От: Max Bowsher
Дата:
Сообщение: Re: git: uh-oh
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: patch: tsearch - some memory diet