<html><body><div>On 07 Apr, 2011,at 06:34 PM, Ted Kremenek <kremenek@apple.com> wrote:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch">Hi Nicola,</div></div></blockquote>Hello Ted.</div><div><span> </span></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch">I think this is a good proposal. My main concern about this project is the potential impact it will have on compile-time performance and memory footprint of the compiler. I'd like to see in the proposal a plan on measuring regressions on these fronts (which are bound to happen by retaining more information in the ASTs) as well as what is deemed an acceptable level for performance to slide. For example, if compile time regresses by 10%, I would strongly object to the changes. Even 5% would probably be too high.<br>
<br>
The other thing to keep in mind is that any AST changes will also require changes to the PCH format. It's critical that PCH remain efficient, and that whatever changes we make to the AST does not adversely impact how much data is pulled from the PCH file (thus slowing down compile times). For most of the topics you outline I don't think this is an issue, but this is definitely something to keep in mind.<br>
</div></div></blockquote><span> </span></div><div><div>I agree with you. I've updated the proposal to reflect your concern. The new text is on melange at</div><div>http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/gigabytes/1001</div><div><br></div><div>Since this proposal is made up of a number of almost independent issues, performance measurement can</div><div>clearly be done on a per-issue basis. What 'acceptable loss' means in this context will be discussed here.</div></div><div><br></div><div><span></span><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch">I think the proposal covers a bunch of areas, and it is entirely possible that you won't have time to do them all. If you were to tackle this project, my preference is that you work on one area to completion, and then proceed to the next one.<br>
</div></div></blockquote><span> </span></div><div>Your suggestion is entirely right. Every issue will be addressed completely before proceeding to the next. It's better to have</div><div>n totally correct patches than 2*n approximative ones.</div><div><span></span><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch">Cheers,<br>
Ted<br></div></div></blockquote><span> </span></div><div><span>Bye,</span></div><div><span>Nicola</span></div></body></html>