launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Mon, May 9, 2011 at 8:41 PM, Jeroen Vermeulen <jtv@xxxxxxxxxxxxx> 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