<div class="gmail_quote">2009/11/30 Devang Patel <span dir="ltr"><<a href="mailto:devang.patel@gmail.com">devang.patel@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">On Mon, Nov 30, 2009 at 10:14 AM, Nick Lewycky <<a href="mailto:nlewycky@google.com">nlewycky@google.com</a>> wrote:<br>
> What's the memory usage penalty of that on a<br>
> large program?<br>
<br>
</div>I have not measured that yet.<br></blockquote><div><br>I think that's the reason we chose the "on the side" design that we did. Please measure it that so we know what tradeoff we'd be making.<br><br>

</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> If we're willing to pay this memory cost, even for programs that aren't<br>
> using debug info, why not just store pointer to a linked list of metadata<br>
> info in the Instruction and remove the MetadataContext? If it's a 10%<br>
> performance win for debug info we should be able to get the exact same win<br>
> across the board for all metadata with no cost beyond what your patch<br>
> already proposes.<br>
<br>
</div>It all depends on how metadata is used. I am myself not very thrilled<br>
about this patch (hence requesting feedback first), but I'd try every<br>
possible opportunity to speedup -O0 -g compile time :)<br></blockquote></div><br>Sure, I was just thinking it could be made more general. Sparse metadata with the MetadataContext that we have now, dense metadata with a linked-list on the Instruction. If we did this, we could require MDKinds to pick sparse or dense so we don't have to play mix-and-match all the time.<br>

<br>Nick<br><br>