<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;"><br><div><div>On Feb 25, 2013, at 13:23 , Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>I found one possible optimization opportunity that recovers most of this cost. It occurs to me that ExplodedNodes with a ProgramPoint of PreStmtPurgeDeadSymbols are no longer needed after they have a single successor. That is, we use them as a mechanism for processing work in ExprEngine, but they don't appear to be used by any client code in the analyzer once we are done removing dead bindings and have generated a PostStmtPurgeDeadSymbols node.</div><div><br></div><div>With that optimization added on to the extra retained nodes for "interesting lvalue expressions", I only see a 2% increase in memory usage from the original baseline before my change. While that isn't totally awesome, I think that's far more acceptable since it really improves the fidelity of our diagnostics.</div></div></blockquote><br></div><div>Seems reasonable about PreStmtPurgeDeadSymbols, and sounds good for a 2% increase. Lvalues are good to have around for a variety of diagnostics.</div><div><br></div><div>Thanks for looking into this.</div><div>Jordan</div><br></body></html>