[
https://issues.apache.org/jira/browse/STDCXX-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646021#action_12646021
]
Martin Sebor commented on STDCXX-914:
-------------------------------------
Here's a superficially tested patch to optimize
{{__rw_locale::_C_is_managed()}} in
{{[src/locale_body.cpp|http://svn.eu.apache.org/viewvc/stdcxx/trunk/src/locale_body.cpp?revision=651334&view=markup]}}.
It improves the performance of the test case by about 25% by avoiding
expensive tests for named faces in the "C" locale.
\\
\\
{noformat}
Index: src/locale_body.cpp
===================================================================
--- src/locale_body.cpp (revision 712407)
+++ src/locale_body.cpp (working copy)
@@ -1066,6 +1066,15 @@
return false;
}
+ _RWSTD_ASSERT (0 == _C_usr_facets);
+
+ if (_C_all == _C_std_facet_bits && 0 == _C_byname_facet_bits) {
+ // optimized for the C locale
+ _RWSTD_ASSERT (__rw_is_C (_C_name));
+
+ return true;
+ }
+
// unless all facets in the same category come either from
// the C locale or from some named locale the locale object
// containing the facets is not managed (this test doesn't
{noformat}
> sstream ctors inefficient in reentrant modes
> --------------------------------------------
>
> Key: STDCXX-914
> URL: https://issues.apache.org/jira/browse/STDCXX-914
> Project: C++ Standard Library
> Issue Type: Improvement
> Components: 27. Input/Output
> Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0, 4.2.1
> Reporter: Martin Sebor
> Priority: Critical
> Fix For: 4.2.2
>
> Attachments: stdcxx-914-gprof-gcc-4.1.2-12D.txt,
> stdcxx-914-gprof-gcc-4.3.0-12S.txt
>
> Original Estimate: 12h
> Time Spent: 1h
> Remaining Estimate: 11h
>
> As discussed in this [thread|http://markmail.org/message/hqlsw5dq23gx7d4o]
> stream ctors in thread-safe builds are inefficient due to the initialization
> of the mutex data member in every stream, even in those that never use it. As
> soon as binary compatibility rules permit it we should remove the mutex
> and/or defer its initialization until it's needed. It might be possible to
> implement the deferred initialization as early as 4.2.2, or maybe 4.3.
> Complete removal will need to wait until 5.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
