Re: stdc++ issue: extremely long compile time with large number of string literals

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Fri, 10 Jul 2020 at 20:36, Mandeep Sandhu
<mandeepsandhu.chd@gmail.com> wrote:
>
> > 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)?

Just a string literal. A raw string literal is the special kind with
the R prefix.

> >
> > 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?)

They're the same.

> >
> > $ 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)

Yes, that's the slow version.

> >
> > 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?

It's the array of std::string that the std::initializer_list refers to
that causes the problem.

In the faster code there is no array of std::string, it's an array of
const char*. Initializing a const char* can't throw an exception, and
destroying it is a no-op, so there's no exception handling code needed
for the array.