[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
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
> 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
>> 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
>>>> 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
>>>> 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.
>> 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...
More information about the Pharo-users