[LLVMbugs] [Bug 11686] New: Overload candidate computation is a space hog

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=11686

             Bug #: 11686
           Summary: Overload candidate computation is a space hog
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The data structures to store conversion sequences are way too big:

StandardConversionSequence: 48 bytes
UserDefinedConversionSequence: 120 bytes
AmbiguousConversionSequence: 80 bytes
BadConversionSequence: 32 bytes
ImplicitConversionSequence: 128 bytes (union of the last 4 structs + 8 extra
bytes)
OverloadCandidate.Conversions: 544 bytes
(SmallVector<ImplicitConversionSequence, 4>)
OverloadCandidate: 752 bytes

To make matters worse we store the OverloadCandidates in a SmallVector. On a
large source file vector reallocation can easily churn through gigabytes of
memory. malloc on OSX seems not to aggressively reuse memory so we end up
wasting a ton of memory in some cases (I haven't really tracked down what's
causing this though).

Some possible solutions:
- Bit pack structs better (not many opportunities there), reduce SmallVector
size
- Pool allocate OverloadCandidates. llvm's SpecificBumpPtrAllocator doesn't
support iteration, but that can be added.
- Enhance the candidate computation to be lazier (not sure if this is feasible)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.