From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch: tsearch - some memory diet |
Date: | 2010-09-07 16:47:54 |
Message-ID: | AANLkTikrnFO1vCn=Go4pC+F5QPLZZLUCygjNpesH7aBq@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/9/7 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2010-09-07 16:53:42 | Re: patch: tsearch - some memory diet |
Previous Message | Max Bowsher | 2010-09-07 16:47:48 | Re: git: uh-oh |