<div dir="ltr"><div class="gmail_default" style>On Mon, Jan 14, 2013 at 8:37 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br></div><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Jan 14, 2013 at 5:12 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>

> If you use the RefactoringTool, adding Replacement's will auto-deduplicate.<br>
<br>
</div>Ah cool.<br>
<div class="im"><br>
On Mon, Jan 14, 2013 at 5:12 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>
> Use RefactoringTool and make all your replacements in a single tool-run. It<br>
> will apply all changes in the very end.<br>
<br>
</div>For some reason, I was thinking a separate process being run for each<br>
TU, and since I wasn't aware of any kind of centralized<br>
serialization/DB logic for the edits which would then be able to<br>
deduplicate, but I guess they are all just in the same process and are<br>
stored in memory. Is peak resident memory O(#replacements) then? What<br>
kind of memory usage for replacements have you seen in practice?<br></blockquote><div><br></div><div style>For llvm-sized projects I think that's not going to be a problem (or you have very old hardware :P)</div><div style>
For Google-sized projects (> 100MLOC) you'll want to serialize the replacements in some form (perhaps from a MapReduce or similar :), deduplicate them, and finally load and apply them. We're currently using protocol buffers internally for those formats, so until a dependency to protocol buffers is fine we'll not put that into the main repo.</div>
<div style><br></div><div style>Cheers,</div><div style>/Manuel</div></div></div></div>