Reduced memory footprint of SkColorSpace_A2B

Reduced memory footprint of SkColorSpace_A2B

Joined its fields together as a union to save up to 8*2+17*4 bytes per
instance.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2451903002

[raftias, 2016-10-25 20:32:50]

Description was changed from

==========
Reduced memory footprint of SkColorSpace_A2B

Joined its fields together as a union to save up to 8*2+17*4 bytes per
instance.

BUG=skia:
==========

to

==========
Reduced memory footprint of SkColorSpace_A2B

Joined its fields together as a union to save up to 8*2+17*4 bytes per
instance.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2451903002
==========

[raftias, 2016-10-25 20:36:47]

The CQ bit was checked by raftias@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-25 20:36:50]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-25 20:59:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-25 20:59:41]

Dry run: This issue passed the CQ dry run.

[raftias, 2016-10-25 21:02:42]

Description was changed from

==========
Reduced memory footprint of SkColorSpace_A2B

Joined its fields together as a union to save up to 8*2+17*4 bytes per
instance.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2451903002
==========

to

==========
Reduced memory footprint of SkColorSpace_A2B

Joined its fields together as a union to save up to 8*2+17*4 bytes per
instance.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2451903002
==========

[raftias, 2016-10-25 21:02:42]

raftias@google.com changed reviewers:
+ msarett@google.com, mtklein@google.com

[reed1, 2016-10-25 21:11:49]

reed@google.com changed reviewers:
+ reed@google.com

[reed1, 2016-10-25 21:11:49]

84 bytes is fine, but given that small size (under the assumption that we don't
allocate a boat load of these), is the new code easier or harder to
read/maintain?

[msarett, 2016-10-25 21:15:47]

On 2016/10/25 21:11:49, reed1 wrote:
> 84 bytes is fine, but given that small size (under the assumption that we
don't
> allocate a boat load of these), is the new code easier or harder to
> read/maintain?

FWIW, I suggested considering this in its own CL.  Now that we see what it looks
like, I'd lean towards leaving as is (as Rob suggested originally).

[mtklein_C, 2016-10-25 21:34:26]

On 2016/10/25 at 21:15:47, msarett wrote:
> On 2016/10/25 21:11:49, reed1 wrote:
> > 84 bytes is fine, but given that small size (under the assumption that we
don't
> > allocate a boat load of these), is the new code easier or harder to
> > read/maintain?
> 
> FWIW, I suggested considering this in its own CL.  Now that we see what it
looks like, I'd lean towards leaving as is (as Rob suggested originally).

Me too.