On Wed, Jan 18, 2017 at 8:25 PM, Holger Freyther <hol...@freyther.de> wrote:
>
>> On 14 Jan 2017, at 12:27, Lee Duhem <lee.du...@gmail.com> wrote:
>>
>
> Hi!
>
> another flight, another time to look at it. :)
>
>
>>> if (free < (to - from))
>>> {
>>> - memcpy (_gst_cur_bytecodes->ptr, from, free);
>>> - _gst_cur_bytecodes->ptr += free;
>>> - from += free;
>>> realloc_bytecodes (_gst_cur_bytecodes,
>>> BYTECODE_CHUNK_SIZE + (to - from));
>>> }
>
>
>> The original logic is that if available space in _gst_cur_bytecodes is
>> less than (to - from),
>> it will copy part of contents from `from' to _gst_cur_bytecodes, then
>> allocate more space
>> through realloc_bytecodes(), and copy the rest from `from'. However,
>> the reallocation of
>> _gst_cur_bytecodes may need to copy the content of it to the new location.
>>
>> And the new code will resize the capacity of _gst_cur_bytecodes first,
>> then copy all the contents
>> from `from' to it. In this case, we may save one memcpy call, and
>> some extra copying in
>> realloc_bytecodes().
>
>
> Let's do the math now and compare it. My focus is on the from += free
> and my suspicion is that we now allocate more memory than before.
>
>
> free == 10
> from == 0
> to == 20
> to-fr== 20
>
> Before:
> free < to-from => true
> memcpy of 10 bytes
> from + free = 10
> realloc CHUNK + 10 =
>
> After:
> free < to-from => true
> realloc CHUNK + 20
>
>
> So I agree that the same data is written, ptr will be correct too but
> maybe a tiny bit more memory? What do you think?
>
You are correct.
We could subtract `free' from the new reallocation delta to achieve the same
effect of old code:
realloc_bytecodes (_gst_cur_bytecodes,
BYTECODE_CHUNK_SIZE + (to - from) - free);
Regards,
lee
> holger
_______________________________________________
help-smalltalk mailing list
help-smalltalk@gnu.org
https://lists.gnu.org/mailman/listinfo/help-smalltalk
