public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "nacitar at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/51359] New: std::string::reserve inefficiency/possible accidental behavior with reserve() Date: Wed, 30 Nov 2011 16:55:00 -0000 [thread overview] Message-ID: <bug-51359-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51359 Bug #: 51359 Summary: std::string::reserve inefficiency/possible accidental behavior with reserve() Classification: Unclassified Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned@gcc.gnu.org ReportedBy: nacitar@gmail.com Not entirely sure 3.4.6 is the right version, but I retrieved the sources via: svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc On 11/30/2011. This may be a "bug" in that this behavior was not intended, though it doesn't cause incorrect behavior; just not as efficient as it could be. Anyhow, looking at the code for .reserve(), it lets you pass in how much to reserve. It then has an if statement that determines if it should reallocate, which essentially says: if (provided_reserve != current_capacity || is_shared) { provided_reserve = max(current_size, provided_reserve); _M_clone(); } This is bad for one reason... Suppose you have any random string, and you call reserve with the same value repeatedly. std::string strBloop = "bloop"; strBloop.reserve(0); // this will reallocate, calling _M_clone() strBloop.reserve(0); // this will once again reallocate, calling _M_clone() Also note _M_clone() invokes _S_create() The reason this happens, is that the reserve request is polished in a few ways: - in reserve(): Ensured to be >= size() - in S_create(): capacity is adjusted using some logic involving the page size estimate, as well as some logic rounding it up to 2*old_capacity... Point being, the capacity after these adjustments will most likely NOT be the value you passed to reserve. This is normally fine, because it's efficient. However, it might make more sense to compare: if (adjusted_reserve(provided_reserve) != capacity()) Because every time you pass a given reserve, it gets adjusted using the same math. So hypothetically, say that calling reserve(0) results in capacity() == 5. Calling reserve(0) then causes another reallocation, because 0 != 5... but after the reallocation, capacity() will once again == 5. This might require moving the adjustment logic out of S_create, but it makes far more sense to compare what the resultant capacity would be with the current capacity than the provided reserve (prior to adjustment) to the current capacity (which was adjusted).
next reply other threads:[~2011-11-30 16:40 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-11-30 16:55 nacitar at gmail dot com [this message] 2011-11-30 17:13 ` [Bug libstdc++/51359] " paolo.carlini at oracle dot com 2012-08-15 14:21 ` paolo.carlini at oracle dot com
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=bug-51359-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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: linkBe 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).