New fast path for proxy loading in Voyage
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-td434556... <http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td434556...> 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-tp3707... <http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp3707...>) 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) The package comment contains a workspace doit for comparision, but long story short, for objects covered by the new fast path, you can now materialize more than million objects in the time it previously took to materialize five. Cheers, Henry *Need to check we aren't becoming primitive literals before being ok to include? Seriously? You can do ((StandardFileStream >> #primRead:into:startingAt:count:) literalAt: 1) at: 4 put: 34 to achieve the same that become apparently must at all costs guard against, does that mean we should also introduce the same kind of primitive fail check requirements to at:put:? I get that there are some objects you really don't want to become: due to VM linking them internally in various ways, but checks that apply to *certain instances* of a class, should be unneccessary, imho (or, better, done at the user site)
cool, thanks! copied and merged :P Esteban
On 08 May 2015, at 14:00, Henrik Johansen <henrik.s.johansen@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-td434556... <http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td434556...> 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-tp3707... <http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp3707...>) 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)
The package comment contains a workspace doit for comparision, but long story short, for objects covered by the new fast path, you can now materialize more than million objects in the time it previously took to materialize five.
Cheers, Henry <Voyage-Mongo-Core-HenrikSperreJohansen.55.mcz>
*Need to check we aren't becoming primitive literals before being ok to include? Seriously? You can do ((StandardFileStream >> #primRead:into:startingAt:count:) literalAt: 1) at: 4 put: 34 to achieve the same that become apparently must at all costs guard against, does that mean we should also introduce the same kind of primitive fail check requirements to at:put:? I get that there are some objects you really don't want to become: due to VM linking them internally in various ways, but checks that apply to *certain instances* of a class, should be unneccessary, imho (or, better, done at the user site)
A few mistakes were revealed when testing using a real application; 1) I'd forgotten to hook up the classFor: method to the proxy creation methods, so it was never actually used... 2) Since copyFrom: is just a pseudo-forwardBecome:, we need to explicitly replace existing references to the value returned by selectOne: ... I hope the repository cache is the only place it is stored during selectOne:, if there are more, additional fixup post copyFrom: in becomeForwardWithSameShape: is needed. The attached version should fix the above two issues. Cheers, Henry
On 08 May 2015, at 2:09 , Esteban Lorenzano <estebanlm@gmail.com> wrote:
cool, thanks! copied and merged :P
Esteban
On 08 May 2015, at 14:00, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@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-td434556... <http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td434556...> 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-tp3707... <http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp3707...>) 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)
The package comment contains a workspace doit for comparision, but long story short, for objects covered by the new fast path, you can now materialize more than million objects in the time it previously took to materialize five.
On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen < henrik.s.johansen@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-td434556... 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-tp3707...) 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.
The package comment contains a workspace doit for comparision, but long story short, for objects covered by the new fast path, you can now materialize more than million objects in the time it previously took to materialize five.
Cheers, Henry
*Need to check we aren't becoming primitive literals before being ok to include? Seriously? You can do ((StandardFileStream >> #primRead:into:startingAt:count:) literalAt: 1) at: 4 put: 34 to achieve the same that become apparently must at all costs guard against, does that mean we should also introduce the same kind of primitive fail check requirements to at:put:? I get that there are some objects you really don't want to become: due to VM linking them internally in various ways, but checks that apply to *certain instances* of a class, should be unneccessary, imho (or, better, done at the user site)
-- Mariano http://marianopeck.wordpress.com
On 08 May 2015, at 2:12 , Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@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-td434556... <http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td434556...> 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-tp3707... <http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp3707...>) 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
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. If I understand correctly, I can now give up on the idea, because Voyage will be using Slots from now on. Am I right? That's a pity. Nevertheless, keep up the good work! Voyage and Mongo are really a promising and terribly easy to use persistence mechanism! I immediately fell in love when I played with it. Joachim Am 08.05.15 um 15:14 schrieb Henrik Johansen:
On 08 May 2015, at 2:12 , Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> wrote:
On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@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-td434556... 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-tp3707...) 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 Tuchel mailto:jtuchel@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
On 09 May 2015, at 07:54, jtuchel@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 :)
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: 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 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.
That's a pity. Nevertheless, keep up the good work! Voyage and Mongo are really a promising and terribly easy to use persistence mechanism! I immediately fell in love when I played with it.
thanks, glad you find it useful :) Esteban
Joachim
Am 08.05.15 um 15:14 schrieb Henrik Johansen:
On 08 May 2015, at 2:12 , Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>> wrote:
On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@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-td434556... <http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td434556...> 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-tp3707... <http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp3707...>) 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 Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> Fliederweg 1 http://www.objektfabrik.de <http://www.objektfabrik.de/> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com <http://joachimtuchel.wordpress.com/> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Esteban, Am 09.05.15 um 08:26 schrieb Esteban Lorenzano:
On 09 May 2015, at 07:54, jtuchel@objektfabrik.de <mailto:jtuchel@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@gmail.com <mailto:marianopeck@gmail.com>> wrote:
On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@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-td434556... 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-tp3707...) 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@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@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
On 09 May 2015, at 08:48, jtuchel@objektfabrik.de wrote:
Esteban,
Am 09.05.15 um 08:26 schrieb Esteban Lorenzano:
On 09 May 2015, at 07:54, jtuchel@objektfabrik.de <mailto:jtuchel@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.
well.. it is just a method :) also, Iâm not sure you didnât need to adapt it before (because it uses forward become)
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 <http://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@gmail.com <mailto:marianopeck@gmail.com>> wrote:
On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@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-td434556... <http://forum.world.st/Igor-s-fast-become-for-CompiledMethods-in-Cog-td434556...> 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-tp3707... <http://forum.world.st/A-trick-to-speedup-become-but-not-becomeForward-tp3707...>) 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 Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> Fliederweg 1 http://www.objektfabrik.de <http://www.objektfabrik.de/> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com <http://joachimtuchel.wordpress.com/> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> Fliederweg 1 http://www.objektfabrik.de <http://www.objektfabrik.de/> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com <http://joachimtuchel.wordpress.com/> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
On 09/05/15 08:48, jtuchel@objektfabrik.de wrote:
I do, and I wish Voyage had been available when I had to make a decision on the persistence mechanism for kontolino.de
For bookkeeping you're probably better of with a persistence solution that makes different tradeoffs from those of mongodb. Stephan
participants (5)
-
Esteban Lorenzano -
Henrik Johansen -
jtuchel＠objektfabrik.de -
Mariano Martinez Peck -
Stephan Eggermont