From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14970 invoked by alias); 21 May 2010 19:44:19 -0000 Received: (qmail 14961 invoked by uid 22791); 21 May 2010 19:44:18 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 May 2010 19:44:14 +0000 Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o4LJiAx4031686 for ; Fri, 21 May 2010 12:44:12 -0700 Received: from pxi18 (pxi18.prod.google.com [10.243.27.18]) by hpaq2.eem.corp.google.com with ESMTP id o4LJi8nS020032 for ; Fri, 21 May 2010 12:44:09 -0700 Received: by pxi18 with SMTP id 18so1054980pxi.5 for ; Fri, 21 May 2010 12:44:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.88.16 with SMTP id q16mr1524805rvl.156.1274471047958; Fri, 21 May 2010 12:44:07 -0700 (PDT) Received: by 10.141.90.17 with HTTP; Fri, 21 May 2010 12:44:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 May 2010 20:43:00 -0000 Message-ID: Subject: Re: Where does the time go? From: Diego Novillo To: Steven Bosscher Cc: GCC Mailing List Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-05/txt/msg00433.txt.bz2 Interesting. Thanks for gathering this. I did a similar study internally on our C++ codebase. The results are fairly different. In our case, the front end takes a LARGE chunk of the compile time. The numbers below are taken from a full build of one of our applications, consisting of ~4,500 C++ files. These are the aggregated times for an -O0 build (only the first 10 main contributors shown): TOTAL : 11583.19 cpu sec, 3705.69 sys sec, 16012.79 wall sec, 841456705 kB parser : 6057.47 cpu sec, 1717.66 sys sec, 7955.42 wall sec, 580829675 kB name lookup : 1688.17 cpu sec, 1011.80 sys sec, 2750.34 wall sec, 93255238 kB preprocessing : 796.18 cpu sec, 575.73 sys sec, 1777.63 wall sec, 14743549 kB tree |^ dominator : 1067.33 cpu sec, 197.20 sys sec, 1290.34 wall sec, 101280196 kB tree gimplify : 973.18 cpu sec, 175.87 sys sec, 1172.88 wall sec, 96888948 kB garbage collection : 471.20 cpu sec, 22.20 sys sec, 499.94 wall sec, 0 kB expand : 339.34 cpu sec, 39.46 sys sec, 386.19 wall sec, 17818728 kB varconst : 336.20 cpu sec, 45.11 sys sec, 383.70 wall sec, 10064103 kB final : 111.79 cpu sec, 13.64 sys sec, 131.18 wall sec, 801421 kB The front end (parser + name lookup + preprocessing) is taking 78% of the wall clock time. What was surprising is that this ratio is fairly consistently maintained across three kinds of builds: optimized (-O2), not optimized (-O0) and debug (-g -O0). In an optimized build, the difference was that the front end reduced its contribution from 78% to 70%. In all cases, the gimplifier took about 6% of the total compile time. For debug builds, the difference was a 6% of time taken by symout. We are currently looking at ways of speeding up builds internally. Based on this, we are mostly looking at ways of making the front end faster. This profile is fairly consistent across much of our code base. Diego.