public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: "Foelsche, Peter" <Peter_Foelsche@mentor.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: compile time of code using long tuples
Date: Fri, 13 May 2022 19:24:01 +0100	[thread overview]
Message-ID: <CAH6eHdSCEEU5GO1auj7x9uRezzu0wgnPvVpxm1vibaAA=TyZQg@mail.gmail.com> (raw)
In-Reply-To: <CAH6eHdSAr4xWwDmH_Byq-8my0GpgA3bsPiF=K5M8oyrRPvXwuw@mail.gmail.com>

On Fri, 13 May 2022, 19:16 Jonathan Wakely, <jwakely.gcc@gmail.com> wrote:

>
>
> On Fri, 13 May 2022, 19:13 Foelsche, Peter, <Peter_Foelsche@mentor.com>
> wrote:
>
>> I'm the author of some software which dumps out C++ code to be compiled
>> with g++.
>> This code sometimes contains many different and many long tuples. I
>> deduced that long tuples cause rather long compile times.
>> I already wrote some compression, which collects identical entries in
>> such a tuple and moves them into an array.
>> But this compression reduces (run-time) performance.
>> I already wrote different tuple implementations, and one of the compiles
>> much faster than the regular provided std::tuple.
>> What could be the criterium for such a tuple implementation, which makes
>> g++ take more or less compile time assuming the same code using this tuple?
>>
>
> Identical object layout on all targets, meaning size, alignment,
> base-class order, etc. It needs to be ABI-compatible.
>

I interpreted the question as asking what would be needed to replace the
existing std::tuple. I guess you mean what aspects of the implementation
affect compile time.

The number of template instantiations, and the number of overload
candidates for name lookup are probably important.

      reply	other threads:[~2022-05-13 18:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-13 18:13 Foelsche, Peter
2022-05-13 18:16 ` Jonathan Wakely
2022-05-13 18:24   ` Jonathan Wakely [this message]

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='CAH6eHdSCEEU5GO1auj7x9uRezzu0wgnPvVpxm1vibaAA=TyZQg@mail.gmail.com' \
    --to=jwakely.gcc@gmail.com \
    --cc=Peter_Foelsche@mentor.com \
    --cc=gcc-help@gcc.gnu.org \
    /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).