Allow certain SP recorder classes to defer their "begin" operation.

Allow certain SP recorder classes to defer their "begin" operation.

This replaces OwnPtr<...> as a pattern when we're uncertain whether we want
to do this. Heap allocation for this case is unnecessary.

DO NOT SUBMIT: I think this hurts clarity too much.

I think this makes it much less clear at the call site whether the begin
will happen immediately or not, and changing all recorders to defer their
begin will be yet more invasive and noisy.

It also makes the recorders themselves more confusing.

There's also a weird split between parameters supplied at construction and
at begin. If we supplied all at construction, we'd have to do extra work
to compute arguments that don't even apply. If we supplied all at begin,
then all the references would become pointers, and would be null for much of
the lifetime of the object.

[chrishtr, 2015-05-26 18:33:07]

chrishtr@chromium.org changed reviewers:
+ chrishtr@chromium.org

[chrishtr, 2015-05-26 18:33:08]

Could you run this version or the other version of the patch through the
(Android) cluster telemetry bot and see a possible impact? If there is a
significant impact we should commit one version or anther IMO.

[jbroman, 2015-05-26 18:35:49]

On 2015/05/26 18:33:08, chrishtr wrote:
> Could you run this version or the other version of the patch through the
> (Android) cluster telemetry bot and see a possible impact? If there is a
> significant impact we should commit one version or anther IMO.

Other one is in CT now at pdr's request.

I suspect that, like the measurements I mentioned on the original CL indicated,
it is currently dwarfed by the DisplayItem allocations. But we'll see if CT
gives a more definitive result.