Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Speed of passing a string by value vs. const reference

Reply
Thread Tools

Speed of passing a string by value vs. const reference

 
 
James Kanze
Guest
Posts: n/a
 
      05-31-2013
On Friday, May 31, 2013 1:55:04 AM UTC+1, SG wrote:
> On May 30, 3:28*pm, Andreas Dehmel wrote:
> > On Thu, 30 May 2013 02:06:37 -0700 (PDT)
> > SG <(E-Mail Removed)> wrote:
> > > On May 29, 11:46*pm, James Kanze wrote:
> > > > The ubiquitous rule is to pass class types by reference to
> > > > const, other types by value. *Since std:;string is a class type,
> > > > convention says to pass it by reference to const, even if with a
> > > > well written string class, it won't make a significant
> > > > difference.


> > > Some rules are now outdated in the light of move semantics.


> > Nonsense. For container types, a move still implies swapping at
> > least 2-3 pointer-sized members and while this is certainly orders
> > of magnitude faster than copying the whole thing, there's no way
> > this'll be faster than simply dereferencing a pointer.


> Compare


> string flip(string const& cref) {
> string result = cref; // explicit copy,
> // might be unnecessary
> reverse(result.begin(),result.end());
> return result; // NRVO applicable
> }


> with


> string flip(string temp) { // temp might be move-constructed or
> // even constructed directly via
> // copy/move elision
> reverse(temp.begin(),temp.end());
> return temp; // implicitly moved
> }


> You might want to test this with a dummy-string class and count the
> number of copy and move constructions in the following example:


> int main() {
> string foo = flip(flip(flip(flip("hello"))));
> }


> So, no, it's not nonsense. In situations where you have the choice
> between pass-by-value and pass-by-ref-to-const for class types, the
> rule "always take a ref-to-const" is obviously not correct anymore.
> Note that I'm not saying "always use pass-by-value" either.


> You might also want to check Dave Abrahams' article about this with
> the provoking title: "Want speed? Pass by value.":
> http://cpp-next.com/archive/2009/08/...pass-by-value/


Who cares? I want readability and maintainability. Which means
conforming to the usual conventions. If the profiler says that
I must do something else, then I do something else (and I
comment as to why). But otherwise, I write code in the expected
manner, so that the reader isn't surprised.

--
James
 
Reply With Quote
 
 
 
 
SG
Guest
Posts: n/a
 
      05-31-2013
On May 31, 3:50*pm, Andreas Dehmel wrote:
> On Thu, 30 May 2013 17:55:04 -0700 (PDT) SG wrote:
> > On May 30, 3:28*pm, Andreas Dehmel wrote:
> > > On Thu, 30 May 2013 02:06:37 -0700 (PDT) SG wrote:
> > > > On May 29, 11:46*pm, James Kanze wrote:
> > > > > The ubiquitous rule is to pass class types by reference to
> > > > > const, other types by value. *Since std:;string is a class type,
> > > > > convention says to pass it by reference to const, even if with a
> > > > > well written string class, it won't make a significant
> > > > > difference.

>
> > > > Some rules are now outdated in the light of move semantics.

>
> > > Nonsense. For container types, a move still implies swapping at
> > > least 2-3 pointer-sized members and while this is certainly orders
> > > of magnitude faster than copying the whole thing, there's no way
> > > this'll be faster than simply dereferencing a pointer.

>
> > Compare

>
> > * string flip(string const& cref) {
> > * * string result = cref; // explicit copy,
> > * * * * * * * * * * * * * // might be unnecessary
> > * * reverse(result.begin(),result.end());
> > * * return result; * * * *// NRVO applicable
> > * }

>
> > with

>
> > * string flip(string temp) { // temp might be move-constructed or
> > * * * * * * * * * * * * * * *// even constructed directly via
> > * * * * * * * * * * * * * * *// copy/moveelision
> > * * reverse(temp.begin(),temp.end());
> > * * return temp; * * * * * * // implicitly moved
> > * }

>
> You're not measuring the overhead of passing the argument one way
> or another but the copy constructor in the first case, which is
> a completely different issue that can easily be avoided by using
> string result(cref.rbegin(), cref.rend()) rather than call reverse
> on a copy. I'd call this a pathological textbook example with zero
> practical relevance; one can always construct these, that doesn't
> mean anything.


I don't think there is a big difference between

string result = cref;
reverse(result.begin(),result.end());

and

string result (cref.rbegin(),cref.rend());

in terms of performance. In both cases you'll have a free store
allocation which is exactly what can be avoided in certain cases by --
oddly enough -- taking the argument by value.

Look Andreas, I simply objected to the simple rule of "always take
class types by ref-to-const" which you had to answer with "Nonsense".
I gave you an example where this rule would mean unnecessary heap
allocation, something your version of flip still does.

> Plus moving the argument in the second case will
> not be possible if you don't call the function with a temporary,


If it's not a temporary there will be almost no difference between all
the functions. They all create a new string object and make it contain
the reversed string value, something a string usually does by asking
the free store for a chunk of memory which one expects to be a lot
slower than swapping three pointers.

> so performance will vary considerably for rather obscure reasons
> (and still be slower when not calling with a temporary).


In the case of an Lvalue argument, it might be a little bit slower,
yes. But that's probably nothing compared to an unnecessary free store
allocation which it can save.

I'm actually surprized to see such resistance against rethinking the
"always take a ref-to-const for class types" idea. James made it sound
like removing a "const&" suddently makes the code less maintainable
and readable. I find such a claim rather ridiculous, to be honest.

I stand by what I said.

Cheers!
SG
 
Reply With Quote
 
 
 
 
SG
Guest
Posts: n/a
 
      05-31-2013
On May 31, 4:11*pm, James Kanze <(E-Mail Removed)> wrote:
> Who cares? *I want readability and maintainability.


These are certainly desirable things. But in case you have forgotten:
this thread's title begins with "speed of passing a string...".
Anyhow, I don't see how removing a "const&" from a function's
signature somehow makes code less readable and less maintainable.

Cheers!
SG
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      05-31-2013
SG wrote:
> On May 31, 4:11 pm, James Kanze <(E-Mail Removed)> wrote:
>> Who cares? I want readability and maintainability.

>
> These are certainly desirable things. But in case you have forgotten:
> this thread's title begins with "speed of passing a string...".
> Anyhow, I don't see how removing a "const&" from a function's
> signature somehow makes code less readable and less maintainable.


Possibly because a future maintainer, used to following convention, will
put it back!

I agree with James, follow convention unless profiling shows you should
do otherwise and when you don't, *comment*.

Conventions are just guidelines, not inviolable rules.

--
Ian Collins
 
Reply With Quote
 
Andreas Dehmel
Guest
Posts: n/a
 
      06-01-2013
On Fri, 31 May 2013 10:18:30 -0700 (PDT)
SG <(E-Mail Removed)> wrote:

> On May 31, 3:50*pm, Andreas Dehmel wrote:


[...]
> I'm actually surprized to see such resistance against rethinking the
> "always take a ref-to-const for class types" idea. James made it sound
> like removing a "const&" suddently makes the code less maintainable
> and readable. I find such a claim rather ridiculous, to be honest.


I concede that there are _very_ special cases where pass by value can
be faster than const reference and maybe there are even some with any
real world relevance. For this to be true, however, you also need
_very_ specific prerequisites, like in your example returning a
modified version of a temporary argument. In other words: you really
have to know what you're doing and what the compiler is doing for
this to work, otherwise you're likely to make things much worse. Not
"early-optimization worse", _much_ worse than that. Now, people who
really know what they're doing don't ask how they're supposed to
pass strings in newsgroups. And you know what happens when people
who don't really know what they're doing get told pass-by-value
might be just as fast or faster? They always pass by value because
it's convenient and that's what they read some "expert" saying
somewhere; hell, they might even do it for all types, even ones
that don't have move semantics to begin with. I've seen this sort
of thing happen often enough. And I hope I don't have to tell you
what a colossal mess this will result in.

So due to this I stand by the current guideline "always pass class-
types by const reference". We can add "unless you really, really know
what you're doing" as a footnote, but that's true for all guidelines
anyway and the odd rvalue loophole won't change that in the least.



Andreas
--
Dr. Andreas Dehmel Ceterum censeo
FLIPME(ed.enilno-t@nouqraz) Microsoft esse delendam
http://www.zarquon.homepage.t-online.de (Cato the Much Younger)

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      06-02-2013
On Friday, May 31, 2013 6:21:47 PM UTC+1, SG wrote:
> On May 31, 4:11*pm, James Kanze <(E-Mail Removed)> wrote:
> > Who cares? *I want readability and maintainability.

>
> These are certainly desirable things. But in case you have forgotten:
> this thread's title begins with "speed of passing a string...".


So this thread is concerned with how to write bad code.

> Anyhow, I don't see how removing a "const&" from a function's
> signature somehow makes code less readable and less maintainable.


Replacing a simple rule with a more complex one always makes
code less readable and less maintainable. Especially when the
more complex rule depends in internal implementation details.

--
James
 
Reply With Quote
 
Balog Pal
Guest
Posts: n/a
 
      06-02-2013
On 6/2/2013 3:46 PM, James Kanze wrote:
> On Friday, May 31, 2013 6:21:47 PM UTC+1, SG wrote:
>> On May 31, 4:11 pm, James Kanze <(E-Mail Removed)> wrote:
>>> Who cares? I want readability and maintainability.

>>
>> These are certainly desirable things. But in case you have forgotten:
>> this thread's title begins with "speed of passing a string...".

>
> So this thread is concerned with how to write bad code.
>
>> Anyhow, I don't see how removing a "const&" from a function's
>> signature somehow makes code less readable and less maintainable.

>
> Replacing a simple rule with a more complex one always makes
> code less readable and less maintainable. Especially when the
> more complex rule depends in internal implementation details.


IMO this particular ting should not be a big deal. I have a couple of
documentation-only macros that translate to nothing. Would make the
signature read (BYVAL string s) that states the fact it was an
intentional choice. client code shall not notice any difference from
signature changes between const& and by-value. Same for programmers.

The only involved party I see is implementer of the function.

Those not using sig annotations can do the same using old-fashioned
comment at the implementation site.

Maitainance-wise I fail to see the difference using either approach.
Especially considering it a rare case that fits the 'don't sweat over
the small stuff' category.

 
Reply With Quote
 
woodbrian77@gmail.com
Guest
Posts: n/a
 
      06-02-2013
On Sunday, June 2, 2013 1:46:11 PM UTC, James Kanze wrote:
> On Friday, May 31, 2013 6:21:47 PM UTC+1, SG wrote:
>
> > On May 31, 4:11*pm, James Kanze <(E-Mail Removed)> wrote:
> > > Who cares? *I want readability and maintainability.

> >
> > These are certainly desirable things. But in case you have forgotten:
> > this thread's title begins with "speed of passing a string...".

>
> So this thread is concerned with how to write bad code.


Like it or not, there are a lot of pesky rules to consider
if we aim to write quality software. I'm sympathetic to
SG's talk about rethinking the matter.

I wish I could be of more help in this and other matters,
but am sorry to report that the Minnesota legislature
recently passed a bill that legalizes "gay" marriage.
Like the Mayflower pilgrims who voted with their feet
for a more G-dly society, I'm now thinking about moving
the company to a more conservative and ethical state.
One of the reasons I started Ebenezer Enterprises was I
wasn't willing to work for a company that used part of the
money I helped it make to support immorality. IBM, Intel,
HP, Google, Microsoft, etc. are the Goliath(s) of these
days. They are too full of it to be bothered with a
simple rule about marriage.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
 
Reply With Quote
 
Bo Persson
Guest
Posts: n/a
 
      06-02-2013
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote 2013-06-02 20:19:
>
> I wish I could be of more help in this and other matters,
> but am sorry to report that the Minnesota legislature
> recently passed a bill that legalizes "gay" marriage.
> Like the Mayflower pilgrims who voted with their feet
> for a more G-dly society, I'm now thinking about moving
> the company to a more conservative and ethical state.
> One of the reasons I started Ebenezer Enterprises was I
> wasn't willing to work for a company that used part of the
> money I helped it make to support immorality. IBM, Intel,
> HP, Google, Microsoft, etc. are the Goliath(s) of these
> days. They are too full of it to be bothered with a
> simple rule about marriage.
>


They are not forcing you to marry anyone against your will, are they?

So what's the big deal, and how does it affect your ability to answer
IT-related questions?


Bo Persson

 
Reply With Quote
 
woodbrian77@gmail.com
Guest
Posts: n/a
 
      06-02-2013
On Sunday, June 2, 2013 7:33:56 PM UTC, Bo Persson wrote:
>
> They are not forcing you to marry anyone against your will, are they?
>


No, but I would be forced to help pay for the benefits
of what is imo immoral. The legislature in its infinite
wisdom has seen fit to redefine marriage which has been
between a man and woman for thousands of years.

> So what's the big deal, and how does it affect your ability to answer
> IT-related questions?
>


The time/money needed to move is a big deal and that
affects my ability to contribute to various matters.

If you are a C++ developer in a US state that still
has the traditional understanding of marriage and would
like to have Ebenezer Enterprises in your backyard,
please let me know.


Brian
Ebenezer Enterprises - Many are the afflictions of the
righteous, but the L-rd delivers him from them all.
http://webEbenezer.net
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
is const necessary in eg int compar(const void *, const void *) lovecreatesbeauty@gmail.c0m C Programming 26 11-10-2008 09:47 PM
non-const reference and const reference George2 C++ 10 12-17-2007 02:19 PM
const vector<A> vs vector<const A> vs const vector<const A> Javier C++ 2 09-04-2007 08:46 PM
Casting int'** to 'const int * const * const' dosn't work, why? Jonas.Holmsten@gmail.com C Programming 11 07-01-2007 06:16 PM
Passing by const & and returning a temp vs passing by value and returningit Victor Bazarov C++ 25 03-23-2005 04:24 PM



Advertisments