<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;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 1, 2017, at 8:05 PM, David Sweeris via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">In "SILFunction.h", line 171, it says,<div class=""><div style="margin: 0px; font-size: 18px; line-height: normal; font-family: 'Fantasque Sans Mono'; color: rgb(120, 142, 149); background-color: rgb(0, 57, 70);" class=""><span style="color: #a4b0b1" class=""> </span>/// The function's set of semantics attributes.</div><div style="margin: 0px; font-size: 18px; line-height: normal; font-family: 'Fantasque Sans Mono'; color: rgb(120, 142, 149); background-color: rgb(0, 57, 70);" class=""><span style="color: #a4b0b1" class=""> </span>///</div><div style="margin: 0px; font-size: 18px; line-height: normal; font-family: 'Fantasque Sans Mono'; color: rgb(120, 142, 149); background-color: rgb(0, 57, 70);" class=""><span style="color: #a4b0b1" class=""> </span>/// TODO: Why is this using a std::string? Why don't we use uniqued</div><div style="margin: 0px; font-size: 18px; line-height: normal; font-family: 'Fantasque Sans Mono'; color: rgb(120, 142, 149); background-color: rgb(0, 57, 70);" class=""><span style="color: #a4b0b1" class=""> </span>/// StringRefs?</div><div style="margin: 0px; font-size: 18px; line-height: normal; font-family: 'Fantasque Sans Mono'; color: rgb(164, 176, 177); background-color: rgb(0, 57, 70);" class=""> llvm::SmallVector<std::string, <span style="color: #e5493d" class="">1</span>> SemanticsAttrSet;</div></div><div class=""><br class=""></div><div class="">As an outside contributor, seeing as how I have no idea why a std::string was used instead of a uniqued StringRef (or TBH, even what it means to "unique" a StringRef in this context), is this the sort of thing I should <i class="">not</i> worry about "fixing"?</div></div></div></blockquote><div><br class=""></div>The TODO is proposing is suggesting that we might want to reduce the overall memory usage of semantics attributes. std::string owns a unique copy of its string data, so if the same semantics attribute is added to many different SILFunctions, you can end up with the same data duplicated many different times. StringRef is basically a raw pointer to string data stored elsewhere, which means two things:</div><div><br class=""></div><div>First, to actually be a memory savings, we want that to be same string data for every use of the same attribute. We can do that by just having a set keyed by strings: you look up the string; if it's there, you use the key data already stored in the set; otherwise, you insert the string into the set. That's all we mean by uniquing; it's also often called "interning" in the context of strings.</div><div><br class=""></div><div>Second, to be safe, that string set needs to outlive the SILFunction. The obvious way to do that is to just store it on the SILModule.</div><div><br class=""></div><div>But... it turns out that we already have a uniquing set for short string data that outlives the SILFunction, and that's the Identifier table in the ASTContext. So the easy change here would be to make this a SmallVector of Identifiers and just look up the attribute string in the Identifier table when adding it.</div><div><br class=""></div><div>I express no opinions about whether this is actually a worthwhile optimization. I suspect that the more important memory savings would be to find a way to not store a full SmallVector on every SILFunction, because while the standard library has quite a few such functions, they're far from the majority case even there, and the proportion is basically 0 when you're talking about user code. Combining these two ideas, we could just switch over to using an llvm::TinyPtrVector<Identifier>.</div><div><br class=""></div><div>John.</div></body></html>