Mailing-List: contact issues-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Message-ID: <1544457943.1210134835896.JavaMail.jira@brutus>
Date: Tue, 6 May 2008 21:33:55 -0700 (PDT)
From: "Martin Sebor (JIRA)" <jira@apache.org>
To: issues@stdcxx.apache.org
Subject: [jira] Issue Comment Edited: (STDCXX-914) sstream ctors inefficient
 in reentrant modes
In-Reply-To: <1774712964.1210133395826.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/STDCXX-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594773#action_12594773 ] 

sebor edited comment on STDCXX-914 at 5/6/08 9:33 PM:
-------------------------------------------------------------

Attached full gprof output for a library and test +this time+ both +really+ compiled with {{-D_RWSTD_USE_STRING_ATOMIC_OPS}} on the command line (see STDCXX-162).

      was (Author: sebor):
    Attached full gprof output for a library and test +this time+ both +really+ compiled with -D_RWSTD_USE_STRING_ATOMIC_OPS on the command line (see STDCXX-162).
  
> 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
>
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> 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.