<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 2, 2013, at 9:58 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">I'm not so worried about the cost of <i>building</i> the map; the analyzer run tends to dwarf any linear-time operations anyway. I just don't want to build it for the entire translation unit, since we won't use most of it and we're already caching the per-function ones. I don't think that's a design issue, though.</div><br class="Apple-interchange-newline"></blockquote></div><div><br></div><div>Agreed. It would be great if a "generic" parent map would just build the parts of the map on demand as necessary. Then all clients could benefit from the optimization of only paying for what you use.</div><br><div>A reasonable approach to stage things would be to first move the current ParentMap to libStaticAnalyzerCore, and have the analyzer use that. Manuel can then feel free to design a more generic data structure, and we can then evaluate whether or not to switch the analyzer over to using that.</div></body></html>