Sounds helpful to me :) Hop on over to the trunk list, and we can talk more about it.
--Mark On 7/18/07, OldPond <[EMAIL PROTECTED]> wrote: > > I would be happy to volunteer performance testing services for development > if required. Ping me if you think this would be useful. > > Mike > > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Rick Copeland > Sent: Wednesday, July 18, 2007 6:27 PM > To: TurboGears > Subject: [TurboGears] Re: Moving to tg2? > > > I haven't looked at the code much since the sprint, but it seems to me > that we might hit performance problems before the Pylons guys do, so > caching the root controller may be a good idea. Here's my thinking... > > In Pylons (with Routes), a "controller" handles a relatively small set > of URLs. Controller construction overhead is therefore quite small, > only constructing the necessary objects to handle that route. In TG2, > a pylons "controller" is actually an entire TG app. So you will > construct your entire URL tree on each request. (Well, not > technically, as there are the special cases of default() and lookup(), > but for other "non-dynamic" URLs, it's true). So caching the root TG2 > controller seems like a _very_ good idea to me. Just my $.02 > > On Jul 18, 11:21 am, "Mark Ramm" <[EMAIL PROTECTED]> wrote: > > > > * TG2 controllers will have __before__ and __after__ methods which > > > > will always be run before or after your controller method > > > > > Nice feature, but it's not directly related with this "create on > > > request" behavior, I suppose... > > > > Yea, it's not directly related, but the way it is implemented is related > :) > > > > > What happens if a method_a does an internal redirect to method_b ? > > > Will __before__ and __after__ be called twice ? > > > > Not in the current implementation. > > > > > > * the ability to rewrite the expose decorator to just decorate the > > > > method with additional attributes. > > > > > Can you elaborate on this ? :) > > > > Sure, the expose decorator currently creates an attribute called > > tg_info on the exposed function/method. That tg_info object has > > information about what engine/template to use to handle which > > requests. So the decorator doesn't really wrap the function, it just > > "decorates" it with additional information. Then the render step > > just looks at the tg_info to to find out what output types are > > supported and what engines to use for them. > > > > Because the controller is recreated on each request, that tg_info > > object can live on the function itself, which makes sense because that > > function is what has the specific behavior we want. Of course, we > > could move tg_info into the pylons request local context object -- but > > that would require adding logic to redirection to clear information > > out of tg_info, so you don't get a new method exposed with the old > > template :( > > > > If there turn out to be performance issues with instantiating the > > controller for each request, I have some ideas about how we can cache > > controller objects -- but I'd like to avoid that kind of complexity > > for now. But the pylons people have been doing it this way for a long > > time, and they tend to be a bit more performance conscious thatn TG > > has been, so I think we'll be OK. > > > > --Mark > > > > > > > -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
