On Mon, May 9, 2011 at 8:41 PM, Jeroen Vermeulen <[email protected]> wrote: > My vague and unsubstantiated concerns are that: (1) Eager-loading the colder > portions of a reference graph may sometimes be a net loss in the grand > scheme of things (considering cold-load speed, hot-load speed, oopses, > engineering time etc.). And that (2) Brittleness in requiring explicit > exceptions to break out of eager-loading may provide false justification for > accepting those losses.
If we use it in a request, we use it, and eager loading along an appropriate dimension is better. If we don't use it we shouldn't load it at all. I don't understand (2). > I'm sure wholesale eager loading is faster than no eager loading, but do we > know how much bad we'd be accepting with the good? This is where > policy/mechanism separation comes in. Wouldn't we end up with the > hoop-jumping required for optimization, and the pain from the oopses we > introduced, driving our priorities when they should be driven by our actual > performance goals? AFAICS non-intrusive profiling ahead of optimization > would show us the same data and support the same changes, but without these > problems. I'm very data driven, all the eager loading I've put in, or advised others to put in has been data driven. I don't see - in practice - the issues you talk about. We have specific service entry points that are entirely suited for stating their needs, and tolerable idioms to do so. I don't want to let the perfect be the enemy of the good. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
