Some fixes/improvements to libgst

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Some fixes/improvements to libgst

Lee Duhem
Hi,

The attached patch provides some fixes and/or improvements to libgst.
You may want to take a look.

Regards,
lee

2016-12-30  Lee Duhem  <[hidden email]>

* byte.c (_gst_compile_bytecodes): Remove unnecessary copy.
* comp.c (_gst_compile_method): Protect new created `selector' from GC
properly.
* gst-parse.c (expected): Call va_end.

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

0001-libgst-Misc-improvements.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some fixes/improvements to libgst

Holger Freyther

> On 30 Dec 2016, at 07:44, Lee Duhem <[hidden email]> wrote:
>
>

Hi!

sorry for the delay.


> * byte.c (_gst_compile_bytecodes): Remove unnecessary copy.

diff --git a/libgst/byte.c b/libgst/byte.c
index 50ff07c..a90a139 100644
--- a/libgst/byte.c
+++ b/libgst/byte.c
@@ -450,9 +450,6 @@ _gst_compile_bytecodes (gst_uchar * from,

   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));
     }

I think the delta is bigger than necessary? If you remove the
advancing of from, then it should be applied to the delta too?
What do you think?



> * comp.c (_gst_compile_method): Protect new created `selector' from GC
> properly.

yes! makes sense

> * gst-parse.c (expected): Call va_end.

yes! at least according to the OSX manpage.


will apply these two hunks and wait for your feedback on the
first change.

holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Some fixes/improvements to libgst

Lee Duhem
On Sat, Jan 14, 2017 at 3:32 AM, Holger Freyther <[hidden email]> wrote:

>
>> On 30 Dec 2016, at 07:44, Lee Duhem <[hidden email]> wrote:
>>
>>
>
> Hi!
>
> sorry for the delay.
>
>
>> * byte.c (_gst_compile_bytecodes): Remove unnecessary copy.
>
> diff --git a/libgst/byte.c b/libgst/byte.c
> index 50ff07c..a90a139 100644
> --- a/libgst/byte.c
> +++ b/libgst/byte.c
> @@ -450,9 +450,6 @@ _gst_compile_bytecodes (gst_uchar * from,
>
>    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));
>      }
>
> I think the delta is bigger than necessary? If you remove the
> advancing of from, then it should be applied to the delta too?
> What do you think?

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().

>
>
>
>> * comp.c (_gst_compile_method): Protect new created `selector' from GC
>> properly.
>
> yes! makes sense
>
>> * gst-parse.c (expected): Call va_end.
>
> yes! at least according to the OSX manpage.
>
>
> will apply these two hunks

Thank you.

Regards,
lee

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Some fixes/improvements to libgst

Holger Freyther

> On 14 Jan 2017, at 12:27, Lee Duhem <[hidden email]> 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?

holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Some fixes/improvements to libgst

Lee Duhem
On Wed, Jan 18, 2017 at 8:25 PM, Holger Freyther <[hidden email]> wrote:

>
>> On 14 Jan 2017, at 12:27, Lee Duhem <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Some fixes/improvements to libgst

Holger Freyther

> On 7 Feb 2017, at 15:43, Lee Duhem <[hidden email]> wrote:
>
>>
>> is what I am pushing through travis-ci right now. Can you give it a try as well?
>
> I tested on Ubuntu 14.04, x86-64.  No regression observed, looks good.
>

great and I pushed the wrong (not rebased/edited) branch yesterday but
all the comments actually seem fine (even the ones I didn't want to
have removed).

I made a follow-up patch to add - free to it.

holger


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk