From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id D25313857022 for ; Fri, 10 Jul 2020 19:36:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D25313857022 Received: by mail-pj1-x1032.google.com with SMTP id b92so3032098pjc.4 for ; Fri, 10 Jul 2020 12:36:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JVkN5kL3sWjfbIh/ynjurgDBVkbU24VnKPgNsqx1+t8=; b=eJzi2DnrMZWgousAQcPcfoDO08sMiHR93SZeB9VMCkRj+6+QGlO6Pgn3IZmkBh8idu LOacVGXx8SmsHGFpwC+JdNCeLAYCcIIXJMgNqEt6siVcIWBiQ6cf89/VR0lczBYqHJbK G1IP/AN8nYZ6pbXiem3DqxO6rC/yUCu5QxWuBLbzM/mrozz86Qh+2r6+83wIKTwVtCvC TOJkDNhCspRHq1znMqwqJhV16Q/4noZOk/3RYYEBdNA+6ILtLSTjGZfJeRIUF7NLjVJn rQS0t0KnqeHRa3EohrZQa8/WBFUjw0LpuQQ8W+AJGH+XQPnZodqUzlGcWfmDvDWigqgL 3vyg== X-Gm-Message-State: AOAM531gzBa54ReuIylxZNiI+GhBLmusmWTaWUyS7PmrfGgpvg7Dr1bg /zCQPXltWP32aLkMDkEwzaqxOO1fq0zGvVKWn/4= X-Google-Smtp-Source: ABdhPJwTxOjDdWUHTcvsm2g+Ve50Ivfx4RwXOEhH98wtE4y8Qgk6sKLykGiCR/PK6P4TeSq0sICXmsbOHC02WhjBPFw= X-Received: by 2002:a17:902:6906:: with SMTP id j6mr17661121plk.125.1594409776446; Fri, 10 Jul 2020 12:36:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mandeep Sandhu Date: Fri, 10 Jul 2020 12:36:05 -0700 Message-ID: Subject: Re: stdc++ issue: extremely long compile time with large number of string literals To: Jonathan Wakely , gcc-help@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 19:36:19 -0000 > Please reply to the mailing list, not just to me. Sorry, this must've happened by mistake (I almost always to a Reply-all when replying to messages from mailing lists) > > > > Thanks for the explanation. Still surprising that the performance > > degraded so much! Will this destruction loop run in quadratic time? > > No, only the compilation time is quadratic. The runtime performance > should be linear in the number of elements. Right, my question was poorly worded. When I said "Will this destruction loop run in quadratic time", I meant the time the compiler takes to create the exception handling code for N-1 elements. > I don't think you mean "raw string literals", do you? > "Raw string" has a very specific meaning: > https://en.cppreference.com/w/cpp/language/string_literal You're right, no I did not mean the one mentioned above (with the R prefix). Whats the correct term for a const char* (which is what I meant)? > > Your email subject says "large number of string literals" but what > your code actually does is create a large > std::initializer_list, which is not the same. > > If you do create string literals and then construct from that it > compiles much faster. This is similar to your original: Just to be sure I follow you, the following invokes std::initializer_list std::unordered_set s ({"a", "b", ...}); // this is what I reported the issue with but this does not? std::unordered_set s {"a", "b", ...}; (and is faster?) > > $ printf '#include \n#include > \nstd::unordered_set s{\n' > init.C ; seq > --format='"%.0f",' 1 50000 >> init.C ; printf '};\n' >> init.C > $ time g++ init.C -c > > real 1m57.054s > user 1m55.370s > sys 0m1.117s On my machine, this too compiles forever (its been compiling for 20+ mins. I'm running on macbook with quad-core i7 & 8GB RAM) > > This creates an array of string literals and then constructs from that: > > $ printf '#include \n#include > \nstd::unordered_set make_set() {\nconst char* > arr[] = {\n' > init2.C ; seq --format='"%.0f",' 1 50000 >> init2.C ; > printf '};\nreturn std::unordered_set{std::begin(arr), > std::end(arr)};\n}\nauto s = make_set();\n' >> init2.C > tmp$ time g++ init2.C -c > > real 0m0.662s > user 0m0.591s > sys 0m0.069s > > As you can see, this is almost instant. Indeed it is! Although I have no idea why. Won't this form also require the same kind of exception handling code? when its iterating "arr", won't the compiler have to still ensure that prior objects are deleted if constructing a string obj from the current element fails? Or maybe the slowness comes from the way initializer_list specifically handles this? Thanks for your time. -mandeep