On Fri, May 8, 2015 at 9:00 AM, Henrik Johansen < 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. > 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
