[Pharo-users] New fast path for proxy loading in Voyage

jtuchel at objektfabrik.de jtuchel at objektfabrik.de
Sat May 9 02:48:34 EDT 2015


Esteban,

Am 09.05.15 um 08:26 schrieb Esteban Lorenzano:
>
>> On 09 May 2015, at 07:54, jtuchel at objektfabrik.de 
>> <mailto:jtuchel at objektfabrik.de> wrote:
>>
>> Hi guys,
>>
>> I am fascinated by Voyage and was about to take a look at how much 
>> effort it might be to port it to VA Smalltalk for a project that 
>> doesn't have the option of moving away from it.
>
> that’s cool, I never hear about people using it in other dialects :)

Not yet. But I can think of uses for it on a project. I am at an early stage
>
>>
>> If I understand correctly, I can now give up on the idea, because 
>> Voyage will be using Slots from now on. Am I right?
>
> well… eventually, that will happen, I suppose I will replace the 
> magritte package with slots… but:

You mean Magritte, but not related to Voyage, right?
>
> 1) that will not happen any time soon (at least, just now in Pharo5 we 
> are starting to create the tools to take advantage of slots… so I 
> guess it will be ready “for general consumption” in pharo6… not that 
> we cannot do some experimental stuff, and we will, but I do not thing 
> there will be a replacement for magritte right now)
> 2) even if I do that, nothing forbids other dialect users to keep 
> maintaining/using the magritte branch
>
> now… recent changes from Henrik are meant to take advantage not from 
> slots but the fast-become made by Igor, a become who just works in

Okay, so I misunderstood the use of the word "Slots" in some messages of 
this thread.

> the case of two objects of same size (in that case, it just swap the 
> objects and do not update the full system). This is hopefully a 
> temporal change (while we wait for spur, who implements a general fast 
> become)… I guess this can be rewritten without using the slot builder, 
> but in any case this is too pharo specific to help you… nothing 
> prevents you to do a “compatibility package” that overrides that 
> method and allows you to continue using Voyage.
> Please let’s me know if you do it and you make your packages public 
> for VA users.
>
I'll have to see if this new change makes porting harder (it is hard 
already ;-) ). This will not happen very soon, but it is on my todo list.
If I do it, it will be published on VASTGoodies.
> thanks, glad you find it useful :)
>

I do, and I wish Voyage had been available when I had to make a decision 
on the persistence mechanism for kontolino.de

Joachim

> Esteban
>
>>
>> Joachim
>>
>> Am 08.05.15 um 15:14 schrieb Henrik Johansen:
>>>
>>>> On 08 May 2015, at 2:12 , Mariano Martinez Peck 
>>>> <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen 
>>>> <henrik.s.johansen at veloxit.no 
>>>> <mailto:henrik.s.johansen at veloxit.no>> wrote:
>>>>
>>>>     Hi Esteban!
>>>>     As we talked about on IRC yesterday, I had hoped to employ the
>>>>     fast become discussed in
>>>>     http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td4345568.html
>>>>     to bring faster proxy loading untill Spur arrives.
>>>>     Sadly, it's not present in any current VM's, for reasons unknown*.
>>>>
>>>>     Luckily, the alternative proposed by Levente in the original
>>>>     thread
>>>>     (http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp3707064p3708128.html)
>>>>     is appropriate for our case.
>>>>     As I don't have write-access to Voyage repo, I've attached the
>>>>     package with the changes (which work in both 3.0 and 4.0, but I
>>>>     assume not older, due to using the SlotBuilder for anon subclasses)
>>>>
>>>>
>>>> hahahahah excellent. It was similar to the same idea I have for my 
>>>> proxies in Marea. In my case, what I did is to have 3 types of 
>>>> Proxies (each with each different object "format" -> normal, 
>>>> compact, long), and each of those proxy classes was a 
>>>> "variableSubclass". So then when I received the object to proxify, 
>>>> I would create an instance (the correct one from one of those 3 
>>>> proxy classes) of the size of the object to proxify. Therefore, 
>>>> both, the proxy and the target would have same size and format, and 
>>>> therefore I could simply apply Igor idea.
>>>
>>> Yeah, it's a really nice fast-path, when the VM's become 
>>> implementation usually involves a heap scan...
>>>
>>> In the case of Voyage, we're restricted in that we don't start out 
>>> with a database ID, and not the actual original object, so perfectly 
>>> pre-shaping the proxy is impossible.
>>> Variably sized objects are right out, so I settled on the compromise 
>>> that was easy to do; fixed size objects with equal or greater number 
>>> of instvars as the proxy class.
>>>
>>> To do fast swapping with objects of less than 3 slots, the current 
>>> data held in proxy slots would have to be held somewhere external, 
>>> which is doable, but ugly.
>>> (You can also work around this easily if the performance hit is 
>>> noticeable by adding dummy slots...)
>>> Compact proxies is a really limited use case, since you never store 
>>> any of the builtin ones in buckets directly, you'd have to manually 
>>> make your mapped classes compact.
>>>
>>> Seeing as how it's really just a holdover performance hack till Spur 
>>> is ready for use and become: becomes fast, I don't think it makes 
>>> sense implementing either in the context of Voyage.
>>>
>>> Cheers,
>>> Henry
>>
>>
>> -- 
>> -----------------------------------------------------------------------
>> Objektfabrik Joachim Tuchelmailto:jtuchel at objektfabrik.de
>> Fliederweg 1http://www.objektfabrik.de
>> D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com
>> Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1
>>
>


-- 
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:jtuchel at objektfabrik.de
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20150509/2edc7f24/attachment.html>


More information about the Pharo-users mailing list