Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #37076 > unrolled thread

What practice can get speed improvement in C++?

Back to article view | Back to comp.lang.c++

Contents

  What practice can get speed improvement in C++? fl <rxjwg98@gmail.com> - 2015-07-14 16:53 -0700
    Re: What practice can get speed improvement in C++? Barry Schwarz <schwarzb@dqel.com> - 2015-07-14 17:23 -0700
      Re: What practice can get speed improvement in C++? bartekltg <bartekltg@gmail.com> - 2015-07-15 15:10 +0200
        Re: What practice can get speed improvement in C++? JiiPee <no@notvalid.com> - 2015-07-16 05:00 +0100
          Re: What practice can get speed improvement in C++? Öö Tiib <ootiib@hot.ee> - 2015-07-16 01:04 -0700
            Re: What practice can get speed improvement in C++? JiiPee <no@notvalid.com> - 2015-07-16 16:48 +0100
              Re: What practice can get speed improvement in C++? JiiPee <no@notvalid.com> - 2015-07-16 16:52 +0100
          Re: What practice can get speed improvement in C++? bartekltg <bartekltg@gmail.com> - 2015-07-16 13:23 +0200
            Re: What practice can get speed improvement in C++? Öö Tiib <ootiib@hot.ee> - 2015-07-16 06:54 -0700
              Re: What practice can get speed improvement in C++? bartekltg <bartekltg@gmail.com> - 2015-07-16 17:30 +0200
                Re: What practice can get speed improvement in C++? Öö Tiib <ootiib@hot.ee> - 2015-07-16 11:16 -0700
                  Re: What practice can get speed improvement in C++? bartekltg <bartekltg@gmail.com> - 2015-07-17 17:06 +0200
            Re: What practice can get speed improvement in C++? JiiPee <no@notvalid.com> - 2015-08-04 16:14 +0100
    Re: What practice can get speed improvement in C++? Victor Bazarov <v.bazarov@comcast.invalid> - 2015-07-14 20:29 -0400
      Re: What practice can get speed improvement in C++? woodbrian77@gmail.com - 2015-07-14 19:50 -0700
    Re: What practice can get speed improvement in C++? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2015-07-15 05:07 +0200
    Re: What practice can get speed improvement in C++? Lőrinczy Zsigmond <nospam@for.me> - 2015-07-15 06:38 +0200
    Re: What practice can get speed improvement in C++? Paavo Helde <myfirstname@osa.pri.ee> - 2015-07-15 00:22 -0500
      Re: What practice can get speed improvement in C++? fl <rxjwg98@gmail.com> - 2015-07-16 04:34 -0700
        Re: What practice can get speed improvement in C++? Martijn van Buul <pino@dohd.org> - 2015-07-21 09:28 +0000
    Re: What practice can get speed improvement in C++? Juha Nieminen <nospam@thanks.invalid> - 2015-08-03 08:16 +0000
      Re: What practice can get speed improvement in C++? woodbrian77@gmail.com - 2015-08-03 13:48 -0700
        Re: What practice can get speed improvement in C++? Juha Nieminen <nospam@thanks.invalid> - 2015-08-04 08:21 +0000
          Re: What practice can get speed improvement in C++? Öö Tiib <ootiib@hot.ee> - 2015-08-04 08:07 -0700
          Re: What practice can get speed improvement in C++? woodbrian77@gmail.com - 2015-08-04 10:15 -0700
            Re: What practice can get speed improvement in C++? Bo Persson <bop@gmb.dk> - 2015-08-04 20:09 +0200
              Re: What practice can get speed improvement in C++? woodbrian77@gmail.com - 2015-08-04 12:38 -0700
                Re: What practice can get speed improvement in C++? Bo Persson <bop@gmb.dk> - 2015-08-05 17:03 +0200
                  Re: What practice can get speed improvement in C++? woodbrian77@gmail.com - 2015-08-05 23:32 -0700
              Re: What practice can get speed improvement in C++? Öö Tiib <ootiib@hot.ee> - 2015-08-05 03:55 -0700
            Re: What practice can get speed improvement in C++? Christopher Pisz <nospam@notanaddress.com> - 2015-08-04 14:09 -0500
              Re: What practice can get speed improvement in C++? woodbrian77@gmail.com - 2015-08-04 12:18 -0700
                Re: What practice can get speed improvement in C++? Christopher Pisz <nospam@notanaddress.com> - 2015-08-04 14:50 -0500
                Re: What practice can get speed improvement in C++? Öö Tiib <ootiib@hot.ee> - 2015-08-05 04:11 -0700
            Re: What practice can get speed improvement in C++? Juha Nieminen <nospam@thanks.invalid> - 2015-08-05 08:12 +0000
              Re: What practice can get speed improvement in C++? Martin Shobe <martin.shobe@yahoo.com> - 2015-08-05 08:53 -0500
              Re: What practice can get speed improvement in C++? woodbrian77@gmail.com - 2015-08-05 22:24 -0700
                Re: What practice can get speed improvement in C++? Ian Collins <ian-news@hotmail.com> - 2015-08-06 17:42 +1200
                  Re: What practice can get speed improvement in C++? woodbrian77@gmail.com - 2015-08-05 22:53 -0700
                    Re: What practice can get speed improvement in C++? Öö Tiib <ootiib@hot.ee> - 2015-08-06 00:20 -0700
                    Re: What practice can get speed improvement in C++? Christopher Pisz <nospam@notanaddress.com> - 2015-08-06 10:10 -0500
                  Re: What practice can get speed improvement in C++? Bo Persson <bop@gmb.dk> - 2015-08-06 17:29 +0200
                    Re: What practice can get speed improvement in C++? woodbrian77@gmail.com - 2015-08-06 09:38 -0700
                Re: What practice can get speed improvement in C++? Juha Nieminen <nospam@thanks.invalid> - 2015-08-10 08:25 +0000
    Re: What practice can get speed improvement in C++? pip010 <pip010@gmail.com> - 2015-08-03 04:22 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#37301

fl <rxjwg98@gmail.com> wrote:
> 1. Use reference to replace a direct parameter in function call;

Depends on the parameter type.

> 2. Use register for some frequent variables;
> 3. Use assembly code to replace C code
> 4. Unroll a loop(?)

Those are completely useless and detrimental.

The major design aspect that affects speed is algorithm and data
container choice and implementation. You can "register" and "unroll"
all you like, but if your algorithm or data container is improper for
the task, they won't help you a bit.

If you then want to go to "hacker optimization", then you have to
minimize the amount of dynamic allocations made in the program
(especially those made in a tight inner loop). If instead of a million
individual allocations you can perform just one, your program will
become faster.

C I/O functions, while less safe and less versatile, tend to be faster
than the C++ equivalents. If you can use, for instance, std::fread()
to read a large file, it will be faster than using C++ streams.

If you are number-crunching, then cache locality can have an enormous
effect on speed, but that's a rather advanced topic.

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#37311

On Monday, August 3, 2015 at 3:16:37 AM UTC-5, Juha Nieminen wrote:

> 
> Those are completely useless and detrimental.
> 
> The major design aspect that affects speed is algorithm and data
> container choice and implementation. You can "register" and "unroll"
> all you like, but if your algorithm or data container is improper for
> the task, they won't help you a bit.
> 
> If you then want to go to "hacker optimization", then you have to
> minimize the amount of dynamic allocations made in the program
> (especially those made in a tight inner loop). If instead of a million
> individual allocations you can perform just one, your program will
> become faster.

I think there's a place for std::string, but I use it less 
than previously.  I guess it's back to the future with arrays
of char.


Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer

[toc] | [prev] | [next] | [standalone]

#37323

woodbrian77@gmail.com wrote:
> I think there's a place for std::string, but I use it less 
> than previously.  I guess it's back to the future with arrays
> of char.

How would an array of chars be faster than std::string? Unless you are
using a static array (or somehow reusing the same allocated array,
which becomes a bit complicated)?

(Also note that the major compiler implementations are moving to
short string optimization, which means that if the majority of your
strings are short, then std::string will probably be faster than
using raw C strings.)

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#37325

On Tuesday, 4 August 2015 11:21:29 UTC+3, Juha Nieminen  wrote:
> woodbrian77@gmail.com wrote:
> > I think there's a place for std::string, but I use it less 
> > than previously.  I guess it's back to the future with arrays
> > of char.
> 
> How would an array of chars be faster than std::string?

Array can't but sometimes we can win a lot by using subranges of array.

Essentially what you wrote two posts ago: "If instead of a million individual
allocations you can perform just one, your program will become faster." ;-) 

There are proposals about adding helpers to C++:
'string_view' from Łukasz Mendakiewicz and Herb Sutter https://isocpp.org/files/papers/N3762.html
'array_view' From Jeffrey Yasskin http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3851.pdf

> Unless you are
> using a static array (or somehow reusing the same allocated array,
> which becomes a bit complicated)?

Lot of text processing that uses 'string' will actually win same done
using 'char*'. It is because the most simple operations like usage of  
'std::string::append' versus 'std::strcat' tend to be somewhat faster.

> (Also note that the major compiler implementations are moving to
> short string optimization, which means that if the majority of your
> strings are short, then std::string will probably be faster than
> using raw C strings.)

64 bit implementation can optimize 22 chars plus trailing null 
as "short". If something like 'string_view' will be added to language
as well then the last little excuse left for raw 'char*' usage in C++
is 'argv' of 'main'. ;-) 

[toc] | [prev] | [next] | [standalone]

#37334

On Tuesday, August 4, 2015 at 3:21:29 AM UTC-5, Juha Nieminen wrote:
> woodbrian77@gmail.com wrote:
> > I think there's a place for std::string, but I use it less 
> > than previously.  I guess it's back to the future with arrays
> > of char.
> 
> How would an array of chars be faster than std::string? Unless you are
> using a static array (or somehow reusing the same allocated array,
> which becomes a bit complicated)?
> 

This is interesting

http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array

> (Also note that the major compiler implementations are moving to
> short string optimization, which means that if the majority of your
> strings are short, then std::string will probably be faster than
> using raw C strings.)
> 

I think that's limited to about 20 characters. 

Brian
Ebenezer Enterprises - "America didn't create religious liberty;
religious liberty created America."  Bobby Jindal

http://webEbenezer.net

[toc] | [prev] | [next] | [standalone]

#37335

On 2015-08-04 19:15, woodbrian77@gmail.com wrote:
> On Tuesday, August 4, 2015 at 3:21:29 AM UTC-5, Juha Nieminen wrote:
>> woodbrian77@gmail.com wrote:
>>> I think there's a place for std::string, but I use it less
>>> than previously.  I guess it's back to the future with arrays
>>> of char.
>>
>> How would an array of chars be faster than std::string? Unless you are
>> using a static array (or somehow reusing the same allocated array,
>> which becomes a bit complicated)?
>>
>
> This is interesting
>
> http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
>

Yes, like one of the replies notices - using sprintf to build filenames 
will let you start opening the file 0.12 microseconds earlier.

Wanna bet if someone will notice the speedup?


Bo Persson

[toc] | [prev] | [next] | [standalone]

#37339

On Tuesday, August 4, 2015 at 1:10:21 PM UTC-5, Bo Persson wrote:
> On 2015-08-04 19:15, woodbrian77@gmail.com wrote:
> >>
> >
> > This is interesting
> >
> > http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
> >
> 
> Yes, like one of the replies notices - using sprintf to build filenames 
> will let you start opening the file 0.12 microseconds earlier.
> 
> Wanna bet if someone will notice the speedup?
> 

I think it matters in aggregate.  Programmers generally work on 
processes that run periodically/frequently.  And maybe you change 
a number of std::string objects to arrays of char in your application.  


Brian
Ebenezer Enterprises - If G-d has you on a short leash, every
little bit helps.

http://webEbenezer.net

[toc] | [prev] | [next] | [standalone]

#37351

On 2015-08-04 21:38, woodbrian77@gmail.com wrote:
> On Tuesday, August 4, 2015 at 1:10:21 PM UTC-5, Bo Persson wrote:
>> On 2015-08-04 19:15, woodbrian77@gmail.com wrote:
>>>>
>>>
>>> This is interesting
>>>
>>> http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
>>>
>>
>> Yes, like one of the replies notices - using sprintf to build filenames
>> will let you start opening the file 0.12 microseconds earlier.
>>
>> Wanna bet if someone will notice the speedup?
>>
>
> I think it matters in aggregate.  Programmers generally work on
> processes that run periodically/frequently.  And maybe you change
> a number of std::string objects to arrays of char in your application.
>

And you don't think that actually opening the file will hide the 
difference (being fractions of a microsecond)?


Bo Persson

[toc] | [prev] | [next] | [standalone]

#37359

On Wednesday, August 5, 2015 at 10:03:59 AM UTC-5, Bo Persson wrote:
> On 2015-08-04 21:38, woodbrian77@gmail.com wrote:
> > On Tuesday, August 4, 2015 at 1:10:21 PM UTC-5, Bo Persson wrote:
> >> On 2015-08-04 19:15, woodbrian77@gmail.com wrote:
> >>>>
> >>>
> >>> This is interesting
> >>>
> >>> http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
> >>>
> >>
> >> Yes, like one of the replies notices - using sprintf to build filenames
> >> will let you start opening the file 0.12 microseconds earlier.
> >>
> >> Wanna bet if someone will notice the speedup?
> >>
> >
> > I think it matters in aggregate.  Programmers generally work on
> > processes that run periodically/frequently.  And maybe you change
> > a number of std::string objects to arrays of char in your application.
> >
> 
> And you don't think that actually opening the file will hide the 
> difference (being fractions of a microsecond)?
> 
> 

I'm doing what I can to make things run fast.  This is trading 
some space for some speed.  That seems like a good trade off to me.  
I can't do much to make opening files faster.

If you don't have a lot of money for hardware, software optimizations 
can help.

Brian
Ebenezer Enterprises - Bless G-d, America.
http://webEbenezer.net

[toc] | [prev] | [next] | [standalone]

#37348

On Tuesday, 4 August 2015 21:10:21 UTC+3, Bo Persson  wrote:
> On 2015-08-04 19:15, woodbrian77@gmail.com wrote:
> > On Tuesday, August 4, 2015 at 3:21:29 AM UTC-5, Juha Nieminen wrote:
> >> woodbrian77@gmail.com wrote:
> >>> I think there's a place for std::string, but I use it less
> >>> than previously.  I guess it's back to the future with arrays
> >>> of char.
> >>
> >> How would an array of chars be faster than std::string? Unless you are
> >> using a static array (or somehow reusing the same allocated array,
> >> which becomes a bit complicated)?
> >>
> >
> > This is interesting
> >
> > http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
> >
> 
> Yes, like one of the replies notices - using sprintf to build filenames 
> will let you start opening the file 0.12 microseconds earlier.
> 
> Wanna bet if someone will notice the speedup?

Someone might notice something other but speedup however.
The code in question ignores return value of 'snprintf'. It does not check if
it is less than 255. It does not allocate bigger buffer if it isn't. So most 
important customer who has the application installed in a way that path
to file exceeds the limits of 'fname' will notice that the junk we sold
him does strange things and crashes. ;-)

[toc] | [prev] | [next] | [standalone]

#37336

On 8/4/2015 12:15 PM, woodbrian77@gmail.com wrote:
> On Tuesday, August 4, 2015 at 3:21:29 AM UTC-5, Juha Nieminen wrote:
>> woodbrian77@gmail.com wrote:
>>> I think there's a place for std::string, but I use it less
>>> than previously.  I guess it's back to the future with arrays
>>> of char.
>>
>> How would an array of chars be faster than std::string? Unless you are
>> using a static array (or somehow reusing the same allocated array,
>> which becomes a bit complicated)?
>>
>
> This is interesting
>
> http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
>
>> (Also note that the major compiler implementations are moving to
>> short string optimization, which means that if the majority of your
>> strings are short, then std::string will probably be faster than
>> using raw C strings.)
>>
>
> I think that's limited to about 20 characters.
>
> Brian
> Ebenezer Enterprises - "America didn't create religious liberty;
> religious liberty created America."  Bobby Jindal
>
> http://webEbenezer.net
>


Like all the flawed comparisons, notice they never reserve even though 
the length is known beforehand.


-- 
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---

[toc] | [prev] | [next] | [standalone]

#37337

On Tuesday, August 4, 2015 at 2:09:19 PM UTC-5, Christopher Pisz wrote:
> On 8/4/2015 12:15 PM, woodbrian77@gmail.com wrote:
> > On Tuesday, August 4, 2015 at 3:21:29 AM UTC-5, Juha Nieminen wrote:
> >> woodbrian77@gmail.com wrote:
> >>> I think there's a place for std::string, but I use it less
> >>> than previously.  I guess it's back to the future with arrays
> >>> of char.
> >>
> >> How would an array of chars be faster than std::string? Unless you are
> >> using a static array (or somehow reusing the same allocated array,
> >> which becomes a bit complicated)?
> >>
> >
> > This is interesting
> >
> > http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
> >
> >> (Also note that the major compiler implementations are moving to
> >> short string optimization, which means that if the majority of your
> >> strings are short, then std::string will probably be faster than
> >> using raw C strings.)
> >>
> >
> > I think that's limited to about 20 characters.
> >
> > Brian
> > Ebenezer Enterprises - "America didn't create religious liberty;
> > religious liberty created America."  Bobby Jindal
> >
> > http://webEbenezer.net
> >
> 
> 
> Like all the flawed comparisons, notice they never reserve even though 
> the length is known beforehand.
> 
> 

He makes a comment about that on one of the answers:
  	 
"I even tried to pre-declare and allocate space in the string in my answer, but that actually just caused things to slow down."

Brian
Ebenezer Enterprises - In G-d we trust. 
http://webEbenezer.net

[toc] | [prev] | [next] | [standalone]

#37340

On 8/4/2015 2:18 PM, woodbrian77@gmail.com wrote:
> On Tuesday, August 4, 2015 at 2:09:19 PM UTC-5, Christopher Pisz wrote:
>> On 8/4/2015 12:15 PM, woodbrian77@gmail.com wrote:
>>> On Tuesday, August 4, 2015 at 3:21:29 AM UTC-5, Juha Nieminen wrote:
>>>> woodbrian77@gmail.com wrote:
>>>>> I think there's a place for std::string, but I use it less
>>>>> than previously.  I guess it's back to the future with arrays
>>>>> of char.
>>>>
>>>> How would an array of chars be faster than std::string? Unless you are
>>>> using a static array (or somehow reusing the same allocated array,
>>>> which becomes a bit complicated)?
>>>>
>>>
>>> This is interesting
>>>
>>> http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
>>>
>>>> (Also note that the major compiler implementations are moving to
>>>> short string optimization, which means that if the majority of your
>>>> strings are short, then std::string will probably be faster than
>>>> using raw C strings.)
>>>>
>>>
>>> I think that's limited to about 20 characters.
>>>
>>> Brian
>>> Ebenezer Enterprises - "America didn't create religious liberty;
>>> religious liberty created America."  Bobby Jindal
>>>
>>> http://webEbenezer.net
>>>
>>
>>
>> Like all the flawed comparisons, notice they never reserve even though
>> the length is known beforehand.
>>
>>
>
> He makes a comment about that on one of the answers:
>    	
> "I even tried to pre-declare and allocate space in the string in my answer, but that actually just caused things to slow down."
>
> Brian
> Ebenezer Enterprises - In G-d we trust.
> http://webEbenezer.net
>

I had no such trouble:


// Shared Library
#include "PerformanceTimer.h"

// Standard Library
#include <cstdio>
#include <iostream>
#include <string>
#include <vector>
#include <cmath>

using namespace std;
#define TRIALS 10000000


int main()
{

     vector<double> secondsElapsedPerRun;

     //const char * baseLocation = "baseLocation";
     const string baseLocation = "baseLocation";

     // Let's declare them both before hand rather than just the C version
     // Let's also use std::string::reserve just like we supply the 
length of the c-array
     char fname[255] = {};
     //string fname;
     //fname.reserve(255);

     Shared::PerformanceTimer timer;
     for (int i = 0; i < TRIALS; ++i)
     {
         timer.Start();

         _snprintf_s(fname, 255, "%s_test_no.%d.txt", 
baseLocation.c_str(), i);
         //fname = baseLocation + "_test_no." + std::to_string(i) + ".txt";

         secondsElapsedPerRun.push_back(timer.Stop());
     }

     // Calculate sum
     double sum = 0.0;

     for(vector<double>::iterator vecIter = 
secondsElapsedPerRun.begin(); vecIter != secondsElapsedPerRun.end(); 
++vecIter)
     {
         sum+= *vecIter;
     }

     double average = sum / static_cast<double>(TRIALS);
     cout << "Average: " << average << " seconds" << endl;

     // Calculate variance
     double variance = 0;

     for(vector<double>::iterator vecIter = 
secondsElapsedPerRun.begin(); vecIter != secondsElapsedPerRun.end(); 
++vecIter)
     {
         variance += (*vecIter - average) * (*vecIter - average);
     }

     variance /= static_cast<double>(TRIALS);

     cout << "Variance: " << variance << " seconds" << endl;
     cout << "Std. deviation: " << sqrt(variance) << " seconds" << endl;

     // Windows specific
     system("pause");
}




C++ string
Average: 1.21634e-006 seconds
Variance: 5.56171e-013 seconds
Std. deviation: 7.45769e-007 seconds

C string
Average: 6.3834e-007 seconds
Variance: 4.31959e-012 seconds
Std. deviation: 2.07836e-006 seconds

Seems a bit more fair.


-- 
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---

[toc] | [prev] | [next] | [standalone]

#37349

On Tuesday, 4 August 2015 22:18:47 UTC+3, woodb...@gmail.com  wrote:
> On Tuesday, August 4, 2015 at 2:09:19 PM UTC-5, Christopher Pisz wrote:
> > On 8/4/2015 12:15 PM, woodbrian77@gmail.com wrote:
> > > On Tuesday, August 4, 2015 at 3:21:29 AM UTC-5, Juha Nieminen wrote:
> > >> woodbrian77@gmail.com wrote:
> > >>> I think there's a place for std::string, but I use it less
> > >>> than previously.  I guess it's back to the future with arrays
> > >>> of char.
> > >>
> > >> How would an array of chars be faster than std::string? Unless you are
> > >> using a static array (or somehow reusing the same allocated array,
> > >> which becomes a bit complicated)?
> > >>
> > >
> > > This is interesting
> > >
> > > http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
> > >
> > >> (Also note that the major compiler implementations are moving to
> > >> short string optimization, which means that if the majority of your
> > >> strings are short, then std::string will probably be faster than
> > >> using raw C strings.)
> > >>
> > >
> > > I think that's limited to about 20 characters.
> > >
> > > Brian
> > > Ebenezer Enterprises - "America didn't create religious liberty;
> > > religious liberty created America."  Bobby Jindal
> > >
> > > http://webEbenezer.net
> > >
> > 
> > 
> > Like all the flawed comparisons, notice they never reserve even though 
> > the length is known beforehand.
> > 
> > 
> 
> He makes a comment about that on one of the answers:
>   	 
> "I even tried to pre-declare and allocate space in the string in my answer, but that actually just caused things to slow down."

It is because the 'string::string(string&&)' called in benchmark does move
and if to replace it with 'string::operator=(string&&)' then it will move
anyway (and so release the pointlessly 'reserve'd buffer). 'string::reserve'
has point if you 'append' or '+=' to it.

The whole benchmark is a joke, the outcome of it is passed 
nowhere and the work in 'for' cycle is pointless 'nop' in essence. 
No wonder since real software rarely needs sliced to 254
characters pieces of texts. 

[toc] | [prev] | [next] | [standalone]

#37347

woodbrian77@gmail.com wrote:
> This is interesting
> 
> http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array

They are not doing the same thing. Formatted printing into a static buffer
is not the same thing as building a dynamic string by appending stuff.

If std::sprintf() is sufficient for the task at hand, then definitely
use that. (After all, I did mention in my post that C I/O functions
tend to be more efficient than the C++ equivalents.)

Now, if you were doing the *same* thing in both cases, however, things
may be different. (For one, appending to a C string ought to be slower
than appending to a std::string, if for nothing else, then because
in the former case knowing were to append is an O(n) operation. And
of course dynamically growing the string as needed is a PitA using
C strings.)

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#37350

On 8/5/2015 3:12 AM, Juha Nieminen wrote:
> woodbrian77@gmail.com wrote:
>> This is interesting
>>
>> http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
>
> They are not doing the same thing. Formatted printing into a static buffer
> is not the same thing as building a dynamic string by appending stuff.
>
> If std::sprintf() is sufficient for the task at hand, then definitely
> use that. (After all, I did mention in my post that C I/O functions
> tend to be more efficient than the C++ equivalents.)
>

Just for fun, I run the tests above using Visual Studio 2013 (I used the 
default release options and _snprintf instead of snprintf. I also added 
a test for stringstream performance.) and got the following results.

Length is the length of the string in baseLocation. stream is the 
average time to build the filename using a stringstream. reserve is the 
average time using a string with a reserved buffer. string is using a 
string without using a reserved buffer. Array is the c-style array.

length stream  reserve string  array
12     8.6122  3.7423  4.4735  4.6979 microseconds
78     7.8117  3.7714  4.4523  6.3554 microseconds

Which I think provides evidence for the maxim about measuring.

Martin Shobe

[toc] | [prev] | [next] | [standalone]

#37356

On Wednesday, August 5, 2015 at 3:12:27 AM UTC-5, Juha Nieminen wrote:
> woodbrian77@gmail.com wrote:
> > This is interesting
> > 
> > http://stackoverflow.com/questions/21946447/how-much-performance-difference-when-using-string-vs-char-array
> 
> They are not doing the same thing. Formatted printing into a static buffer
> is not the same thing as building a dynamic string by appending stuff.
> 

How about comparing these two programs:

#include <string.h>

int main ()
{
  for (int i = 0; i < 4000000; ++i){
    char s[200];
    ::strncpy(s, "We few; we happy few; we band of brothers.", sizeof(s));
  }
}

and

#include <string>

int main ()
{
  for (int i = 0; i < 4000000; ++i){
    ::std::string s = "We few; we happy few; we band of brothers.";
  }
}

uname -a
Linux localhost.localdomain 4.0.4-301.fc22.x86_64 #1 SMP Thu May 21 13:10:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.1.1 20150422 (Red Hat 5.1.1-1) (GCC) 


size oldschool stdstr
   text	   data	    bss	    dec	    hex	filename
   1504	    596	      4	   2104	    838	oldschool
   1875	    604	     40	   2519	    9d7	stdstr


The std::string version is over 4 times slower than the
old school version on this machine and even slower on a 
FreeBSD machine.

time ./oldschool 

real	0m0.085s
user	0m0.084s
sys	0m0.002s

time ./stdstr 

real	0m0.365s
user	0m0.363s
sys	0m0.003s



Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[toc] | [prev] | [next] | [standalone]

#37357

woodbrian77@gmail.com wrote:
>
> How about comparing these two programs:
>
> #include <string.h>
>
> int main ()
> {
>    for (int i = 0; i < 4000000; ++i){
>      char s[200];
>      ::strncpy(s, "We few; we happy few; we band of brothers.", sizeof(s));
>    }
> }
>
> and
>
> #include <string>
>
> int main ()
> {
>    for (int i = 0; i < 4000000; ++i){
>      ::std::string s = "We few; we happy few; we band of brothers.";
>    }
> }

A fairer comparison would be

int main ()
{
   std::string s;
   for (int i = 0; i < 4000000; ++i){
     s = "We few; we happy few; we band of brothers.";
   }
}

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#37358

On Thursday, August 6, 2015 at 12:42:31 AM UTC-5, Ian Collins wrote:
> woodbrian77@gmail.com wrote:
> >
> > How about comparing these two programs:
> >
> > #include <string.h>
> >
> > int main ()
> > {
> >    for (int i = 0; i < 4000000; ++i){
> >      char s[200];
> >      ::strncpy(s, "We few; we happy few; we band of brothers.", sizeof(s));
> >    }
> > }
> >
> > and
> >
> > #include <string>
> >
> > int main ()
> > {
> >    for (int i = 0; i < 4000000; ++i){
> >      ::std::string s = "We few; we happy few; we band of brothers.";
> >    }
> > }
> 
> A fairer comparison would be
> 
> int main ()
> {
>    std::string s;
>    for (int i = 0; i < 4000000; ++i){
>      s = "We few; we happy few; we band of brothers.";
>    }
> }
> 


Here's the time for that version.

time ./stdstr 

real	0m0.120s
user	0m0.118s
sys	0m0.001s

In most cases I can't lift a std::string out of the loop like that
though.

[toc] | [prev] | [next] | [standalone]

#37360

On Thursday, 6 August 2015 08:53:58 UTC+3, woodb...@gmail.com  wrote:
> On Thursday, August 6, 2015 at 12:42:31 AM UTC-5, Ian Collins wrote:
> > woodbrian77@gmail.com wrote:
> > >
> > > How about comparing these two programs:
> > >
> > > #include <string.h>
> > >
> > > int main ()
> > > {
> > >    for (int i = 0; i < 4000000; ++i){
> > >      char s[200];
> > >      ::strncpy(s, "We few; we happy few; we band of brothers.", sizeof(s));
> > >    }
> > > }
> > >
> > > and
> > >
> > > #include <string>
> > >
> > > int main ()
> > > {
> > >    for (int i = 0; i < 4000000; ++i){
> > >      ::std::string s = "We few; we happy few; we band of brothers.";
> > >    }
> > > }
> > 
> > A fairer comparison would be
> > 
> > int main ()
> > {
> >    std::string s;
> >    for (int i = 0; i < 4000000; ++i){
> >      s = "We few; we happy few; we band of brothers.";
> >    }
> > }
> > 
> 
> 
> Here's the time for that version.
> 
> time ./stdstr 
> 
> real	0m0.120s
> user	0m0.118s
> sys	0m0.001s
> 
> In most cases I can't lift a std::string out of the loop like that
> though.

We run profiler on full application. We do not write code that has no 
input nor output in tight loops. Therefore such tests are deceiving.
On all cases of composing multi-megabyte XML, JSON or the like (why else
you need to copy 4 millions of texts in tight loop?) that 'strncat' and
the like lose to 'string::append' and the like.

We can win both by hand optimizing usage of bytes (in vector of bytes)
for concrete case but that does give minor returns because the real
bottle-neck is in transfer of data. So if we instead use the effort of
that raw byte level tinkering to find a way to reduce the data transferred
by half then the program is twice faster.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web