Use bit fields inside cc to reduce memory usage.

Use bit fields inside cc to reduce memory usage.

Using bitfields we get the memory usage as follows

+-----+---------------------------+------------------------+---------+
|.No..|.Class/Structure/File......|.Size.of.object.(bytes).|.Memory..|
|.....|...........................+------------------------+.Reduced.|
|.....|...........................|...Before..|...After....|.........|
+-----+---------------------------+-----------+------------+---------+
|..1..|.cc::Layer.................|......840..|.....824....|......16.|
+-----+---------------------------+-----------+------------+---------+
|..2..|.cc::LayerImpl.............|......880..|.....864....|......16.|
+-----+---------------------------+-----------+------------+---------+
|..3..|.cc::RenderSurfaceImpl.....|......408..|.....400....|.......8.|
+-----+---------------------------+-----------+------------+---------+

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=239682

[vivekg, 2013-12-09 12:34:17]

Using the bitfields has got the memory sizes as depicted in above table. I
understand that some of the objects are just one time objects but the others
being created frequently, the total memory saved could be sizable. Please take a
look. Thank you, Vivek.

[danakj, 2013-12-09 18:10:34]

Given those numbers, in practice I could see this saving about 1KB of memory.
That itself does not seem like it's going to change anything, but maybe my
perspective is wrong here?

I'd be more interested in if this could help avoid cache misses particularly on
tree walks. Do you see any effect as that?

[enne (OOO), 2013-12-09 18:26:05]

Let's do this only for Layer/LayerImpl/RenderSurfaceImpl since many of those are
active at once per compositor.  Everything else there's only one of per
compositor and so bitfields don't seem worth it.

I don't understand your table, as you can't add separate object types together
to make a total.

[vivekg, 2013-12-09 20:53:17]

On 2013/12/09 18:10:34, danakj wrote:
> Given those numbers, in practice I could see this saving about 1KB of memory.
> That itself does not seem like it's going to change anything, but maybe my
> perspective is wrong here?
> 
> I'd be more interested in if this could help avoid cache misses particularly
on
> tree walks. Do you see any effect as that?

That's an interesting aspect. I haven't explored it yet but I will check it out
if it has any effect on the cache behavior. Thank you.

[vivekg, 2013-12-09 20:55:54]

On 2013/12/09 18:26:05, enne wrote:
> Let's do this only for Layer/LayerImpl/RenderSurfaceImpl since many of those
are
> active at once per compositor.  Everything else there's only one of per
> compositor and so bitfields don't seem worth it.
> 
> I don't understand your table, as you can't add separate object types together
> to make a total.

Yeah you are correct. The total should not be summed up. I have modified the
patch to just include the suggested objects. I will change the description to
reflect the only affected objects, thank you.

[enne (OOO), 2013-12-09 20:58:10]

Thanks! Can you also update the description to reflect the changes?

[vivekg, 2013-12-09 20:59:43]

On 2013/12/09 20:58:10, enne wrote:
> Thanks! Can you also update the description to reflect the changes?

Done. :)

[enne (OOO), 2013-12-09 21:03:42]

Thanks, lgtm.

[commit-bot: I haz the power, 2013-12-10 01:24:56]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vivek.vg@samsung.com/102733006/20001

[commit-bot: I haz the power, 2013-12-10 05:40:31]

Failed to apply the patch.
Sending        cc/layers/layer.cc
Sending        cc/layers/layer.h
Sending        cc/layers/layer_impl.cc
Sending        cc/layers/layer_impl.h
Sending        cc/layers/render_surface_impl.cc
Sending        cc/layers/render_surface_impl.h
Transmitting file data ......svn: Commit failed (details follow):
svn: File '/trunk/src/cc/layers/layer_impl.cc' is out of date

[commit-bot: I haz the power, 2013-12-10 05:45:37]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vivek.vg@samsung.com/102733006/20001

[commit-bot: I haz the power, 2013-12-10 05:48:54]

Change committed as 239682

[Nico, 2013-12-10 06:37:31]

I happened to see this fly by. I'd like to echo Dana's concerns that unless this
saves hundreds of kB of memory, this doesn't seem worth it (gcc 4.6 generates
invalid implicit move constructors for bitfields in c++11 mode for example, so
it's not a completely academic concern).