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
next prev 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).