Tom,
Yes I agree. It does make a lot of assumptions. I would not consider using
that code permanently without knowing exactly the way the system worked,
and then I'd add error checking code that would detect misuse and/or
overflow at run time. We use this type of allocation scheme for real time
rendering where I work without any problems.
I think the system would benefit greatly from using a simple memory
allocation scheme instead of the brute force malloc() method when it needs
temporary storage during a prepare(), step(), and finalize() sequence.
Matt
Tom
<[EMAIL PROTECTED]
> To
[email protected]
01/10/2005 01:39 cc
PM
Subject
Re: [sqlite] excessive malloc()
Please respond to calls
[EMAIL PROTECTED]
te.org
I am sorry, typing too fast I had made typos which made my message not
understandable. So here it is again:
I would say it is one of the most dangerous code snippets I have seen
in a while.
The code makes a lot of assumptions but they are NOT explicitly stated.
It may work under some strictly defined conditions but after several
months you or anyone else modifying the code may forget what those
conditions were and it would lead to a memory corrupting bug which
would be very hard to trace.
Tom
Abracode
On Jan 10, 2005, at 3:15 PM, Tom wrote:
> I would say it is one of the most dangerous code snippets I have seen
> in a while.
> The code makes a lot of assumption but they are explicitly stated. It
> may work under some strictly defined conditions but after several
> months you or anyone else modifying may forget what those conditions
> were and it would lead to a memory corrupting bug which would be very
> hard to trace.
>
> Tom
> Abracode
>
> On Jan 10, 2005, at 2:39 PM, [EMAIL PROTECTED] wrote:
>
>> Windows XP, visual studio .NET.
>> The malloc call ends up calling RtlAllocateHeap().
>>
>> I hacked the code to allocate the aType structure from a circular ring
>> buffer. This small change made my app go from spending 60% of its
>> time in
>> malloc to about 3%.
>>
>> Here's the allocator I hacked in. No freeing is needed, the buffer
>> just
>> wraps. This assumes that by the time a wrap occurs, memory perviously
>> allocated at the top is no longer needed. It seems to work ok from my
>> limited testing. :-)
>>
>> #define SQLITE_WORK_BUFF_SIZE (128*1024) // make power of 2
>> #define SQLITE_WORK_BUFF_MASK (SQLITE_WORK_BUFF_SIZE-1)
>> char sqlite_workBuff[SQLITE_WORK_BUFF_SIZE];
>> int sqlite_writeIdx=0;
>>
>> void *SQLITE_ALLOC(int nBytes)
>> {
>> void *ret;
>> sqlite_writeIdx = (sqlite_writeIdx + nBytes) &
>> SQLITE_WORK_BUFF_MASK;
>> ret = sqlite_workBuff + sqlite_writeIdx;
>> sqlite_writeIdx+=nBytes;
>> return ret;
>>
>> }
>>
>> Matthew Arrington
>> Sony Computer Entertainment America
>
>
>
