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
<marianop...@gmail.com <mailto:marianop...@gmail.com>> wrote:
On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen
<henrik.s.johan...@veloxit.no <mailto:henrik.s.johan...@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 Tuchel mailto:jtuc...@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
