public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/103755] New: {has,use}_facet() and iostream constructor performance
@ 2021-12-17  3:49 dprokoptsev at gmail dot com
  2021-12-17 10:31 ` [Bug libstdc++/103755] " redi at gcc dot gnu.org
                   ` (19 more replies)
  0 siblings, 20 replies; 21+ messages in thread
From: dprokoptsev at gmail dot com @ 2021-12-17  3:49 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 103755
           Summary: {has,use}_facet() and iostream constructor performance
           Product: gcc
           Version: 11.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dprokoptsev at gmail dot com
  Target Milestone: ---

Created attachment 52021
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52021&action=edit
Proposed implementation

Current implementation of basic_ios::init(), through invocation of
_M_cache_locale(), calls has_facet() and use_facet() on three facet types
(ctype, num_get, num_put). As each one of them does a dynamic_cast under the
hood, a mere construction of an iostream results in six (6) dynamic_casts,
resulting in poor performance in cases of short-lived iostreams.

However, one can note that these {has,use}_facet() only reference facets which
present in classic() locale and therefore are guaranteed to be there in any
locale (with the matching type) and therefore don't require any bounds checks
or dynamic_casts in the locale impl object. So we can do some TMP to establish
a subset of facets which are always present in any locale, and instruct
has_facet() and use_facet() to bypass any checks for those.

(It may also be worth it to add __try_use_facet() function, providing more
efficient version of (has_facet<T>(loc) ? &use_facet<T>(loc) : 0)).

I've drafted a patch implementing changes described above. On my hardware
(i9-9900k @ 5 GHz) it reduces iostream construction time from 100 ns down to 36
ns).

^ permalink raw reply	[flat|nested] 21+ messages in thread
end of thread, other threads:[~2023-04-21 15:06 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-17  3:49 [Bug libstdc++/103755] New: {has,use}_facet() and iostream constructor performance dprokoptsev at gmail dot com
2021-12-17 10:31 ` [Bug libstdc++/103755] " redi at gcc dot gnu.org
2021-12-17 17:22 ` redi at gcc dot gnu.org
2021-12-17 17:52 ` redi at gcc dot gnu.org
2021-12-17 21:05 ` redi at gcc dot gnu.org
2021-12-19  3:41 ` dprokoptsev at gmail dot com
2021-12-19  3:44 ` dprokoptsev at gmail dot com
2021-12-19 13:04 ` redi at gcc dot gnu.org
2022-02-03 17:06 ` redi at gcc dot gnu.org
2022-09-23 12:57 ` redi at gcc dot gnu.org
2022-11-11  5:29 ` cvs-commit at gcc dot gnu.org
2022-11-11 13:27 ` redi at gcc dot gnu.org
2022-11-11 21:54 ` seurer at gcc dot gnu.org
2022-11-11 21:55 ` redi at gcc dot gnu.org
2022-11-11 22:39 ` redi at gcc dot gnu.org
2022-11-12  1:30 ` cvs-commit at gcc dot gnu.org
2022-11-12  2:00 ` redi at gcc dot gnu.org
2023-01-06 12:12 ` redi at gcc dot gnu.org
2023-01-11 14:07 ` redi at gcc dot gnu.org
2023-04-21 15:01 ` cvs-commit at gcc dot gnu.org
2023-04-21 15:06 ` 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).