Robert Bradshaw wrote: > On Sep 8, 2008, at 7:41 AM, Lisandro Dalcin wrote: > > >> I have some working code following Dag advices (BTW, that transform >> stuff its a real win!). >> > > Yes, it certainly is! One thing that worries me is that adding a > bunch of tree traversals starts to slow things down--at the very > least we should have a transform that doesn't descend into function > bodies for speed reasons for stuff like this. > Lisandro simply shouldn't call self.visitchildren in visit_FuncDefNode, no new transform type is needed.
For the record (re: transforms): 1) If they enable us to more quickly develop to a point where Cython can self-compile, then that likely win backs what we temporarily loose (more tree-traversals is only a constant-time overhead after all, and quick function dispatches during traversals will likely win back what we loose?). (A compiler slowdown for about a year is perhaps not "temporary" enough though...) 2) The transform framework could be extended to be able to merge transforms. For instance: pipeline = [PostParseTransform(...), ..., MergeNonConflicting(A, B, C, D), ...] where you know that A, B, C and D are not interfering with one another and can be executed "simultaneously" in one sense (the restriction here is that a B for a given node only depends on the previous siblings and ancestors with respect to what is done by A). So MergeNonConflicting simply takes the result of visit_FuncDefNode of A and feeds it directly to visit_FuncDefNode of B. Many nodes are leaves and the tree is shallow so perhaps it doesn't win that much; but the visitor dispatch only needs to be used once (i.e. the types of the nodes are looked at less times) so perhaps there is some potential here *shrug*. For my own uses, gcc still uses *a lot* more running-time than Cython, so I don't have an itch to scratch here -- how are things in SAGE? Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
