[LLVMbugs] [Bug 23395] New: raw_svector_ostream will heap allocate without need

[bugzilla-daemon at llvm.org]

https://llvm.org/bugs/show_bug.cgi?id=23395

            Bug ID: 23395
           Summary: raw_svector_ostream will heap allocate without need
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: yaron.keren at gmail.com
                CC: chandlerc at gmail.com, chisophugis at gmail.com,
                    dexonsmith at apple.com, llvmbugs at cs.uiuc.edu,
                    rafael.espindola at gmail.com
    Classification: Unclassified

The code line

 OS.reserve(OS.size() + 64);

called from raw_svector_ostream::write_impl called from
raw_svector_ostream::~raw_svector_ostream will heap allocate without need. The
issue is already documented:

raw_svector_ostream::~raw_svector_ostream() {
  // FIXME: Prevent resizing during this flush().
  flush();
}

And a solution is provided in raw_svector_ostream::init():

  // Set up the initial external buffer. We make sure that the buffer has at
  // least 128 bytes free; raw_ostream itself only requires 64, but we want to
  // make sure that we don't grow the buffer unnecessarily on destruction (when
  // the data is flushed). See the FIXME below.
  OS.reserve(OS.size() + 128);

This solution may be worse than the problem. In total:

* If the SmallString was less than 128 bytes init() will always(!) heap
allocate. 
* If it's more or equal to 128 bytes but upon destruction less than 64 bytes
are left unused it will heap allocate for no reason. 

A careful programmer who did size the SmallString to match its use + small
reserve will find either of these heap allocations surprising, negating the
SmallString advantage and then paying memcpy cost.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150502/bd439485/attachment.html>