public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/110739] New: std::format for chrono types compiles very slowly
@ 2023-07-19 11:33 redi at gcc dot gnu.org
  2023-07-19 11:40 ` [Bug libstdc++/110739] " redi at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2023-07-19 11:33 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110739

            Bug ID: 110739
           Summary: std::format for chrono types compiles very slowly
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Keywords: compile-time-hog
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Some of the compilation overhead is unavoidable, because we need to parse the
format string during constant evaluation.

But as it says in this comment in bits/chrono_io.h:

      // TODO this function template is instantiated for every different _Tp.
      // Consider creating a polymorphic interface for calendar types so
      // that we instantiate fewer different specializations. Similar to
      // _Sink_iter for std::format. Replace each _S_year, _S_day etc. with
      // member functions of that type.
      template<typename _Tp, typename _FormatContext>
        typename _FormatContext::iterator
        _M_format(const _Tp& __t, _FormatContext& __fc,
                  bool __is_neg = false) const

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/110739] std::format for chrono types compiles very slowly
  2023-07-19 11:33 [Bug libstdc++/110739] New: std::format for chrono types compiles very slowly redi at gcc dot gnu.org
@ 2023-07-19 11:40 ` redi at gcc dot gnu.org
  2023-07-19 12:55 ` redi at gcc dot gnu.org
  2023-07-25 10:52 ` redi at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2023-07-19 11:40 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110739

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2023-07-19

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 55579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55579&action=edit
Instantiate less code for chrono formatters

           * include/bits/chrono_io.h (__formatter_chrono): Use
            if-constexpr to avoid instantiating function bodies for types
            that can never be used with those functions.

This patch helps a little bit, but less than I'd hoped it would.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/110739] std::format for chrono types compiles very slowly
  2023-07-19 11:33 [Bug libstdc++/110739] New: std::format for chrono types compiles very slowly redi at gcc dot gnu.org
  2023-07-19 11:40 ` [Bug libstdc++/110739] " redi at gcc dot gnu.org
@ 2023-07-19 12:55 ` redi at gcc dot gnu.org
  2023-07-25 10:52 ` redi at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2023-07-19 12:55 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110739

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 55580
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55580&action=edit
Instantiate less code for chrono formatters, take 2

In this patch the converters like _S_date and _S_hms are called by _M_format
before passing the argument to _M_x, _M_d_e etc. so that those function
templates are only called with arguments that are already the right type. This
reduces the number of different instantiations of those function templates.

But this doesn't really help either.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug libstdc++/110739] std::format for chrono types compiles very slowly
  2023-07-19 11:33 [Bug libstdc++/110739] New: std::format for chrono types compiles very slowly redi at gcc dot gnu.org
  2023-07-19 11:40 ` [Bug libstdc++/110739] " redi at gcc dot gnu.org
  2023-07-19 12:55 ` redi at gcc dot gnu.org
@ 2023-07-25 10:52 ` redi at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2023-07-25 10:52 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110739

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Explicit instantiation declarations+definitions might help, both in <chrono>
and <format>.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-07-25 10:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-19 11:33 [Bug libstdc++/110739] New: std::format for chrono types compiles very slowly redi at gcc dot gnu.org
2023-07-19 11:40 ` [Bug libstdc++/110739] " redi at gcc dot gnu.org
2023-07-19 12:55 ` redi at gcc dot gnu.org
2023-07-25 10:52 ` redi at gcc dot gnu.org

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