Re: [Pharo-project] Replace ByteArray with a smaller one

2012-11-07 Thread Camillo Bruni
if the chunks you wan to cut off are big enough you could
potentially allocate a new object there which get's gc-ed.

But I have no clue how to do that without VM / NB support ;)


On 2012-11-07, at 14:39, Mariano Martinez Peck  wrote:

> Hi guys. I have a ByteArray of size N.
> And I want now only the same ByteArray but from 1 to N-X. I am using
> #copyFrom:to: but that one answers a new copy. If the ByteArray is large,
> this takes time because it needs to allocate a large object. In my case I
> don't care and I can modify the original ByteArray itself (lets say make it
> smaller, null the remaining part and change the object header info). That
> way I would avoid an extra allocation. Is there a primitive for that?
> 
> Thanks!
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com




Re: [Pharo-project] Replace ByteArray with a smaller one

2012-11-07 Thread Igor Stasenko
On 7 November 2012 11:11, Camillo Bruni  wrote:
> if the chunks you wan to cut off are big enough you could
> potentially allocate a new object there which get's gc-ed.
>
yes..
actually you can 'crop' the existing object by modifying its size
field (so VM will know it)
and then for the rest bytes, mark them as a 'free chunk', which designates a
unused memory space in heap.

actually, this could be a good candidate for a primitive.
But imo, much better strategy is to not allocate too big arrays. :)

Also, as alternative , you can create a 'ArraySlice' collection class,
which is a view on existing array but with smaller number or elements.
And pass it around as a valid collection.

> But I have no clue how to do that without VM / NB support ;)
>
>
> On 2012-11-07, at 14:39, Mariano Martinez Peck  wrote:
>
>> Hi guys. I have a ByteArray of size N.
>> And I want now only the same ByteArray but from 1 to N-X. I am using
>> #copyFrom:to: but that one answers a new copy. If the ByteArray is large,
>> this takes time because it needs to allocate a large object. In my case I
>> don't care and I can modify the original ByteArray itself (lets say make it
>> smaller, null the remaining part and change the object header info). That
>> way I would avoid an extra allocation. Is there a primitive for that?
>>
>> Thanks!
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>
>



-- 
Best regards,
Igor Stasenko.



Re: [Pharo-project] Replace ByteArray with a smaller one

2012-11-08 Thread Mariano Martinez Peck
On Thu, Nov 8, 2012 at 4:24 AM, Igor Stasenko  wrote:
> On 7 November 2012 11:11, Camillo Bruni  wrote:
>> if the chunks you wan to cut off are big enough you could
>> potentially allocate a new object there which get's gc-ed.
>>
> yes..
> actually you can 'crop' the existing object by modifying its size
> field (so VM will know it)
> and then for the rest bytes, mark them as a 'free chunk', which designates a
> unused memory space in heap.
> actually, this could be a good candidate for a primitive.


Exactlly. I was hoping there was already a primitive for that :(


> But imo, much better strategy is to not allocate too big arrays. :)
>
> Also, as alternative , you can create a 'ArraySlice' collection class,
> which is a view on existing array but with smaller number or elements.
> And pass it around as a valid collection.
>
>> But I have no clue how to do that without VM / NB support ;)
>>

:(


>>
>> On 2012-11-07, at 14:39, Mariano Martinez Peck  wrote:
>>
>>> Hi guys. I have a ByteArray of size N.
>>> And I want now only the same ByteArray but from 1 to N-X. I am using
>>> #copyFrom:to: but that one answers a new copy. If the ByteArray is large,
>>> this takes time because it needs to allocate a large object. In my case I
>>> don't care and I can modify the original ByteArray itself (lets say make it
>>> smaller, null the remaining part and change the object header info). That
>>> way I would avoid an extra allocation. Is there a primitive for that?
>>>
>>> Thanks!
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>



--
Mariano
http://marianopeck.wordpress.com