Rectangle swallow:

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

Rectangle swallow:

Nicolas Cellier
I put an experimental SLICE in the inbox: let a Rectangle merge in
place (I called this swallow:)
This has two advantages:
- avoid repeated Object creation when we just want the gross result
- avoid closures writing to outer temps

IMHO, generalizing this kind of policy could have a measurable impact
on GUI speed.
However, this is against current policy to never change a Point nor
rectangle in place, so I let gurus judge if worth or not.

cheers

Nicolas

Reply | Threaded
Open this post in threaded view
|

Re: Rectangle swallow:

Colin Putney

On 2009-12-27, at 1:56 PM, Nicolas Cellier wrote:

> I put an experimental SLICE in the inbox:

What's a SLICE?

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Rectangle swallow:

Levente Uzonyi-2
On Sun, 27 Dec 2009, Colin Putney wrote:

>
> On 2009-12-27, at 1:56 PM, Nicolas Cellier wrote:
>
>> I put an experimental SLICE in the inbox:
>
> What's a SLICE?

It's an MC hack to add changes from different packages to one new package.
It's described here: http://code.google.com/p/pharo/wiki/HowToContribute


Levente

>
> Colin
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Rectangle swallow:

Igor Stasenko
In reply to this post by Nicolas Cellier
2009/12/27 Nicolas Cellier <[hidden email]>:

> I put an experimental SLICE in the inbox: let a Rectangle merge in
> place (I called this swallow:)
> This has two advantages:
> - avoid repeated Object creation when we just want the gross result
> - avoid closures writing to outer temps
>
> IMHO, generalizing this kind of policy could have a measurable impact
> on GUI speed.
> However, this is against current policy to never change a Point nor
> rectangle in place, so I let gurus judge if worth or not.
>

Oh , you mean, that this method modifying the state of existing
Rectangle instance,
instead of producing new one?
It is certaintly more optimal, especially in Morphic world. But it
should be used with care,
since sometimes you don't know, how many other morphs refer to same
rectangle instance or
where it came from.

> cheers
>
> Nicolas
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Rectangle swallow:

Nicolas Cellier
2009/12/28 Igor Stasenko <[hidden email]>:

> 2009/12/27 Nicolas Cellier <[hidden email]>:
>> I put an experimental SLICE in the inbox: let a Rectangle merge in
>> place (I called this swallow:)
>> This has two advantages:
>> - avoid repeated Object creation when we just want the gross result
>> - avoid closures writing to outer temps
>>
>> IMHO, generalizing this kind of policy could have a measurable impact
>> on GUI speed.
>> However, this is against current policy to never change a Point nor
>> rectangle in place, so I let gurus judge if worth or not.
>>
>
> Oh , you mean, that this method modifying the state of existing
> Rectangle instance,
> instead of producing new one?
> It is certaintly more optimal, especially in Morphic world. But it
> should be used with care,
> since sometimes you don't know, how many other morphs refer to same
> rectangle instance or
> where it came from.
>

Yes exactly that's the problem and that's why I ask.
I used it in a very controlled fashion over-protecting with a probably
unecessary copy in the preamble.
But you never know how the message will be used once you release it...
Anyway, some benchmark would be necessary before touching these bits...

Nicolas

>> cheers
>>
>> Nicolas
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Rectangle swallow:

Andreas.Raab
Nicolas Cellier wrote:
> Yes exactly that's the problem and that's why I ask.
> I used it in a very controlled fashion over-protecting with a probably
> unecessary copy in the preamble.
> But you never know how the message will be used once you release it...
> Anyway, some benchmark would be necessary before touching these bits...

I'm actually in favor of making this the default behavior of #merge:.
We'd need some operation (merged:?) that ensures a copy but I don't
think that creating a copy on every merge: request is useful.
Rectangle>>quickMerge: agrees.

Cheers,
   - Andreas