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