On Mon, Jan 31, 2011 at 9:56 AM, Patrick R. Michaud <[email protected]> wrote: > 3. Serialization. The major item that makes Rakudo startup so slow > is that we have to do so much initialization at startup to get > Rakudo's type system and setting in place. > There's not a good > way in Parrot to reliably serialize a set of language-defined types,
In order for me to prioritize, which problem is this? One with serializing classes and objects? Or the one involving dynpmcs? > nor to attach compile-time attributes to subroutines and other "static" > objects in the bytecode itself You are hitting the limits of PIR's syntax. It is very poor at expressing concepts related to arbitrary PMC constants. Parrot provides this functionality, mostly simply by not getting in the way. I don't think there is any way we can improve this within the constraints of PIR, and it follows that any compiler that targets PIR will not have an easy time in this area. Get away from PIR (and we're working to provide you the tools to do this), and you most likely will not have this issue. > Another issue with Parrot serialization is that it often tends to > be a "serialize the world" affair -- serializing a data structure > ultimately ends up serializing the underlying class data types, > their superclasses, and the like. There needs to be a mechanism > for placing boundaries around the serialization; to serialize only > the unique pieces of a model, as opposed to everything it references. This is on the radar. Back-references within PBC was the first step towards cross-references between PBCs, which is how jnthn described to me what was needed. > We're working on strategies to do better serialization from within > nqp, but Parrot definitely needs to explore this area as well > and devise some strategies for compile-time creation of > language-specific data structures, instead of requiring them > to always be built at program initialization. > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
