public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mandeep Sandhu <mandeepsandhu.chd@gmail.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>, gcc-help@gcc.gnu.org
Subject: Re: stdc++ issue: extremely long compile time with large number of string literals
Date: Fri, 10 Jul 2020 12:36:05 -0700	[thread overview]
Message-ID: <CAC+QLdS+hG1tjUr9SQR-J1tmxYjMnHYgL5ioC7zfyUzK_+B3mw@mail.gmail.com> (raw)
In-Reply-To: <CAH6eHdTRiwA3t1K3okfVc+umPM8PJfbePaO7AHdLz+SYPOU9XQ@mail.gmail.com>

> 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<std::string>, 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::string>
std::unordered_set<std::string> s ({"a", "b", ...}); // this is what I
reported the issue with

but this does not?
std::unordered_set<std::string> s {"a", "b", ...}; (and is faster?)

>
> $ printf '#include <unordered_set>\n#include
> <string>\nstd::unordered_set<std::string> 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 <unordered_set>\n#include
> <string>\nstd::unordered_set<std::string> make_set() {\nconst char*
> arr[] = {\n' > init2.C ; seq --format='"%.0f",' 1 50000 >> init2.C ;
> printf '};\nreturn std::unordered_set<std::string>{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

  parent reply	other threads:[~2020-07-10 19:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 20:31 Mandeep Sandhu
2020-07-09 20:49 ` Marc Glisse
2020-07-09 21:27   ` Mandeep Sandhu
2020-07-09 23:49 ` Jonathan Wakely
     [not found]   ` <CAC+QLdRqjTe4YsUpQRcLG7tpxGda0oh6H788ORZa5MQR3NqRbw@mail.gmail.com>
     [not found]     ` <CAH6eHdTRiwA3t1K3okfVc+umPM8PJfbePaO7AHdLz+SYPOU9XQ@mail.gmail.com>
2020-07-10 19:36       ` Mandeep Sandhu [this message]
2020-07-10 20:25         ` Jonathan Wakely
2020-07-11  6:27           ` Mandeep Sandhu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC+QLdS+hG1tjUr9SQR-J1tmxYjMnHYgL5ioC7zfyUzK_+B3mw@mail.gmail.com \
    --to=mandeepsandhu.chd@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).