<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 27, 2009, at 3:51 PM, Alexei Svitkine wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">Oops - it looks like there was a change to ParseAST() earlier that I<br>wasn't up to date with. This one:<br><br><a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011412.html">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090126/011412.html</a><br><br>That change involves propagating the FreeMemory param to the<br>ASTContext constructor... which is problematic with my change which<br>gets rid of that param entirely. I'm not sure how to handle this.</span></blockquote><div><br></div><div>The "FreeMemory" argument to ASTContext is a little of a misnomer. It's more a selector of which Allocator that ASTContext uses to allocate ASTs (i.e., MallocAllocator or BumpPtrAllocator). Calling ~ASTContext() will *always* release memory. Feel free to rename that parameter to something more appropriate.</div><div><br></div><div>Much of your patch is orthogonal to these changes. Your patch is about creating a new interface for ParseAST that allows clients to hold on the TranslationUnit/ASTContext after ParseAST has completed.</div><div><br></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">What is the purpose of -disable-free in the context of the<br>command-line clang tool?</span></blockquote><br></div><div>Our timings show that a significant amount of time is spent in clang freeing ASTs.</div><div><br></div><div>When invoking 'clang' for compilation from the command-line, freeing ASTs is a waste of time since the OS will automatically reclaim that memory. Providing -disable-free from the command line allows us to experiment with the performance of just having the OS free memory versus freeing the memory directly.</div><div><br></div><div>Moreover, having it as a command-line option (rather than hard-coded) allows us to free memory ASTs manually for debugging (to make sure all the ownership issues are correct) but still have the --disable-free option for production releases.</div></body></html>