On Thu, Sep 23, 2010 at 6:14 PM, Nick Lewis <[email protected]> wrote:
> >> Ah, this must be something that Paul has changed recently. What holds >> a reference to the AST now, since it's not the known resource types? >> >> > > It's not merged, but it's in the fix for ticket #4656. ASTs (and templates) > are now being cached by the environment. They could actually probably be > cached globally, but there's nowhere that really makes sense to put them. > > Just to be clear: the patch for #4656 that went to the list on September 2 _is_ option I. The reason for this RFC is that I got some very reasonable push-back from Markus when I submitted it--he said it was too pervasive a change to make without getting community input first, and he was right. That's why we did this RFC. When Nick and I worked on patch #4656 we did some speed tests and we have good reason to believe the performance impact of option I is small. The change that allows option I to have a low performance impact is 4da88fb4cd57871f16649d50572240ac3f7420f0, which got merged into next on August 17. It extends the AST concept so that instead of having a separate mini-AST for each class, definition and node (as we do in 2.6) that get merged into known_resource_types during parsing, we switch to a more conventional compilation model where there is a single large AST for each file, and that gets split up along class boundaries and inserted into known_resource_types as a separate step at the end of parsing. The new separate step is quite fast, and it's the only thing that gets executed more times in option I. I now believe, based on the discussion I've seen in this thread, that the patch I submitted for #4656 was the wrong approach (and hence, option I is the wrong approach). It addressed the nondeterminism in a roundabout way by re-doing work in order to make sure that past compiles done by the master wouldn't affect future compiles. But it didn't address the underlying issues that led to the nondeterminism, namely: confusing and unexpected semantics of autoloading. The solution I think we're converging on (based on option II) solves the nondeterminism by making autoloading work in a sane and predictable way, and that's IMHO a much better way to go. Paul > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<puppet-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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/puppet-dev?hl=en.
