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��
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.


��
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