public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/46347] New: Profile-mode executables too large
@ 2010-11-07 15:48 paolo.carlini at oracle dot com
  2010-11-11 23:14 ` [Bug libstdc++/46347] " rus at google dot com
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: paolo.carlini at oracle dot com @ 2010-11-07 15:48 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46347

           Summary: Profile-mode executables too large
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: paolo.carlini@oracle.com


I believe we should seriously investigate whether we can reduce the size of the
profile-mode executables. Likely that means we have also to add exports, but
the current status seems really pretty bad. Just as a trivial example, on
mainline today (rev 166416), x86_64, -O2, we have, for

#include <vector>

int main()
{
  std::vector<int> v(100);
  v.push_back(2);
}

the following sizes:

 normal-mode:    12184
  debug-mode:    17370
profile-mode:   130345


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/46347] Profile-mode executables too large
  2010-11-07 15:48 [Bug libstdc++/46347] New: Profile-mode executables too large paolo.carlini at oracle dot com
@ 2010-11-11 23:14 ` rus at google dot com
  2010-11-11 23:53 ` paolo.carlini at oracle dot com
  2010-12-10 16:54 ` paolo.carlini at oracle dot com
  2 siblings, 0 replies; 4+ messages in thread
From: rus at google dot com @ 2010-11-11 23:14 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46347

--- Comment #1 from rus at google dot com 2010-11-11 23:14:45 UTC ---
The size difference of 100 KB on small tests is actually expected.  The vector
instantiation will trigger instantiation of several profile analysis methods. 
All these methods use internally unordered_map and some use other standard
library components.  I don't know a good way to avoid this.

The compilation time is much higher as well.  The precompiled sources increase
from 5,000 lines to 31,000 lines.  I wonder if this can be reduced somehow.

However, this is a toy example.  I measured binary sizes on medium size
binaries between 1 MB and 10 MB (built -O2 -g0).  The numbers are full binary
sizes, not just text size.  The profile-mode binaries are in between the
original ones and the debug-mode ones, which makes sense given that
profile-mode doesn't have as much coverage as debug-mode.

Paolo, could you please try to reproduce these ratios independently on a larger
binary?  Just to make sure it's not due to some linker mechanism turned on just
in my setup.

           Original   Profile     Debug
Binary  1      8.0M      8.9M       11M
Binary  2      6.0M      6.6M      7.2M
Binary  3      1.5M      2.1M      2.6M
Binary  4      1.6M      2.2M      2.7M
Binary  5      1.6M      2.2M      2.7M
Binary  6      5.8M      6.4M      6.9M
Binary  7      5.9M      6.6M      7.1M
Binary  8      6.4M      7.0M      7.6M
Binary  9      6.0M      6.6M      7.2M
Binary 10      1.6M      2.2M      2.7M
Binary 11      1.7M      2.3M      2.8M
Binary 12      7.4M      8.3M      9.7M
Binary 13      1.5M      2.1M      2.6M
Binary 14      7.4M      8.2M      9.7M
Binary 15      1.5M      2.1M      2.6M
Binary 16      1.6M      2.1M      2.7M
Binary 17      1.6M      2.2M      2.7M
Binary 18      5.9M      6.5M      7.1M
Binary 19      6.0M      6.6M      7.2M
Binary 20      5.7M      6.2M      6.8M
Binary 21      1.5M      2.1M      2.6M
Binary 22      1.2M      1.6M      2.0M
Binary 23      7.6M      8.4M       11M
Binary 24      1.2M      1.7M      2.1M
Binary 25      7.5M      8.3M      9.9M
Binary 26      812K      1.2M      1.4M
Binary 27      1.5M      2.1M      2.6M
Binary 28      1.7M      2.3M      2.8M
Binary 29      8.0K      8.0K      8.0K
Binary 30      8.0K      8.0K      8.0K
Binary 31      8.0K      8.0K      8.0K
Binary 32      8.0K      8.0K      8.0K
Binary 33      1.4M      1.9M      2.4M
Binary 34      1.2M      1.8M      2.2M
Binary 35      1.3M      1.7M      2.1M
Binary 36      1.6M      2.2M      2.7M
Binary 37      812K      1.2M      1.4M
Binary 38      2.2M      2.8M      3.5M
Binary 39      1.1M      1.5M      1.8M
Binary 40      1.6M      2.2M      2.8M
Binary 41      1.7M      2.3M      2.8M
Binary 42      1.5M      2.1M      2.6M
Binary 43      8.0M      8.8M       11M
Binary 44      6.7M      7.3M      8.2M
Binary 45      1.6M      2.1M      2.7M
Binary 46      804K      1.2M      1.4M


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/46347] Profile-mode executables too large
  2010-11-07 15:48 [Bug libstdc++/46347] New: Profile-mode executables too large paolo.carlini at oracle dot com
  2010-11-11 23:14 ` [Bug libstdc++/46347] " rus at google dot com
@ 2010-11-11 23:53 ` paolo.carlini at oracle dot com
  2010-12-10 16:54 ` paolo.carlini at oracle dot com
  2 siblings, 0 replies; 4+ messages in thread
From: paolo.carlini at oracle dot com @ 2010-11-11 23:53 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46347

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> 2010-11-11 23:52:50 UTC ---
Very well, I may well be wrong, I admit to have filed this enhancement PR
basing only on some quite small tests + the definite impression that we have
functions inline in the profile-mode infrastructure headers which are
definitely too large, in general should definitely be exported by the library.
But if we are talking about an overhead which doesn't grow with the size of
user code, the issue seems not so serious. Good. I'd like to double check that,
before closing the issue as invalid, anyway. Also, I'd like to make sure that
we don't run in more serious problems when the coverage is indeed increased -
very soon I hope!


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/46347] Profile-mode executables too large
  2010-11-07 15:48 [Bug libstdc++/46347] New: Profile-mode executables too large paolo.carlini at oracle dot com
  2010-11-11 23:14 ` [Bug libstdc++/46347] " rus at google dot com
  2010-11-11 23:53 ` paolo.carlini at oracle dot com
@ 2010-12-10 16:54 ` paolo.carlini at oracle dot com
  2 siblings, 0 replies; 4+ messages in thread
From: paolo.carlini at oracle dot com @ 2010-12-10 16:54 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46347

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2010-12-10 16:54:00 UTC ---
Let's close this.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-12-10 16:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-07 15:48 [Bug libstdc++/46347] New: Profile-mode executables too large paolo.carlini at oracle dot com
2010-11-11 23:14 ` [Bug libstdc++/46347] " rus at google dot com
2010-11-11 23:53 ` paolo.carlini at oracle dot com
2010-12-10 16:54 ` paolo.carlini at oracle dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).