Code review comment for lp:~albaguirre/mir/back-to-stack-alloc-mir-protobuf

> I know I asked for this. Although now I realize it's actually less efficient
> than using Arenas. Because on the stack your object is indeed allocated super
> fast (adjusting the stack pointer has always taken one clock tick or less).
> But stack allocation doesn't solve the problem for the subobjects (variable
> length lists, strings) that are still allocated on the heap. Arenas however
> solve both problems with the speed of a stack:
>
> https://developers.google.com/protocol-buffers/docs/reference/arenas?hl=en
>
> So I've got nothing against this proposal right now. But if it makes the
> syntax less like the Arena syntax then it might be harder for us to get that
> optimal performance with Arenas in the long run.

Ok, it shouldn't be too difficult to change to Arena based allocation even if this lands, but I need to investigate the code generated when "option cc_enable_arenas = true;" is used.