having to check if the buffer is full - any efficient way to do this ?

Started by Rainstorm, April 11, 2008, 03:33:07 AM

Previous topic - Next topic

Rainstorm

Hi

I have allocated memory for a destination buffer & i have a reallocation function my code.
As far as i can see.. I'd have to check if the buffer is full, in all the loops in my code where i would be writing data into the buffer..- that is, before writing every byte to the destination buffer.
I just wanted to ask is there a more efficient way for doing this other than what i stated above ?

thanks

Tedd

You'd have to work out some of checking less frequently.
So, if you know that one of the loops won't write more than 256 bytes, then you can check there are at least 256 bytes free - then there's no need to check again inside the loop. Of course, it could still succeed if there are less, so you have to choose your chunk size carefully, e.g. only check every 64 bytes.
No snowflake in an avalanche feels responsible.

zooba

Depending on what sort of buffers you are using there are different ways of doing this. File mappings and virtual allocations can use guard pages that throw an exception when written to or read, at which point you can commit the next page. I implemented this once and it worked fine, though it is much easier (and faster) to figure out the total size first.

If you can't possibly know the total size without producing the resulting buffer there are a few options. As Tedd described, break your code up into blocks with a known maximum number of bytes written, then check beforehand. If it is cheap to process your input consider doing it once to find the exact buffer size, allocate, then process the input again to fill it. Alternatively, do it once and store the results in some form of array or list, then allocate the entire buffer and copy the smaller results in (I believe this will be faster than reallocating as you go, but I haven't tried it).

Definitely keep track of the number of bytes left in a register, or, keep a pointer to the end of the buffer in a register or stack variable. This way your comparisons are only one command (dec <register>/jz or cmp <register>,<memory>/ja).

The last suggestion I can make is centralise your code that writes to the buffer. It will require temporary buffers and calls throughout your code, but you will only need to handle reallocation in one place.

Definite things to avoid: Don't check every single byte. Don't expand the buffer one byte at a time.

Hope some of this has helped :bg

Cheers,

Zooba :U

Rainstorm

Ted,
that's a great solution, I get the picture & will try to figure it out in my code. that would make
the code way more efficient. - i couldn't imagine having to check every byte in this case.

Zooba, i forgot to mention am using the memory Heap functions presently. - appreciate the feedback.. but i'll have to look into the method you suggested...as i don't know much about it. - About the buffsize, in this case its not possible for me to properly predict it in advance.. cause the code will be editing files based on the input...at runtime (like replacing txt etc..) so the end filesize... could be more or less than the original.

Just have one more question..
is there a need for creating 2 heap abjects with HeapCreate, OR should i just create one heap object & allocate the seperate blocks needed (using 'HeapAlloc') from that one mem object ??
would appreciate any comments on this..

thanks everyone for the assistancel..

Rainstorm

zooba

Generally you will only need one heap object, and even then you only really need that if the process heap is not sufficient.

If you're modifying text in files and there is no need to buffer the entire file, work in chunks. Read a block of text in and as you search through it simply write it out to a temporary file. At the end, delete (or rename) the original file and rename the temporary file. This way the operating system will handle the buffer as required.

Cheers,

Zooba :U

Rainstorm

Zooba, i've yet to work some of techniques you mentioned, but it gave me some perspective on the whole thing & the choices at hand .

thanks