search for: 286mb

...ince we cannot inject DIEs from > later CUs into prior ones). > > >> 4G MCContext >> > > What's the data in the MCContext that's relevant to debug info? > One data point on "Xalan": without -g, MCContext allocates 45MB, with -g, MCContext allocates 286MB. > > >> --> The memory usage is still too big. >> > > Do we have an idea of what size is "small enough"? It would be useful to > have a goal. > > >> So how to reduce the memory footprint at MDNode level: >> 1> Combine integers int...

...into prior ones). >> >> >>> 4G MCContext >>> >> >> What's the data in the MCContext that's relevant to debug info? >> > > One data point on "Xalan": > without -g, MCContext allocates 45MB, > with -g, MCContext allocates 286MB. > OK, might be useful to understand which parts of that - maybe the Values (ints, strings, etc) themselves are being attributed to the MCContext rather than the MDNode sizes you were reporting above? Not really sure. -------------- next part -------------- An HTML attachment was scrubbed... UR...

Hi Manman, Thanks for sending this summary and progress plans - it's great to see the impact your changes have had and ideas for future direction. Type uniquing for C++ is in. Some data for Xalan with -flto -g: > 9.9MB raw dwarf size, peak memory usage at 2.8GB > The raw dwarf size was 58MB, memory usage was 7GB back in May, 2013. > Other efforts at size reduction helped, and type

Hi All, Type uniquing for C++ is in. Some data for Xalan with -flto -g: 9.9MB raw dwarf size, peak memory usage at 2.8GB The raw dwarf size was 58MB, memory usage was 7GB back in May, 2013. Other efforts at size reduction helped, and type uniquing improved on top of those. Data on building clang with "-flto -g" after type uniquing: 3.4GB MDNodes after parsing all bc files, 7GB