#define for optimization

[Lowest0ne]

A while back I read about a way for either gcc, or gnu, or something to help optimize a program. One had to add a certain #define and then maybe also a compiler flag. It might behave like this:

1 2 3 4 5 6 7 8 9 10

#include <vector> int main( void ) { std::vector< int > numbers; for ( int i = 0; i < 100; ++i ) numbers.insert( numbers.begin(), i ); return 0; }

$ ./a.out Using std::vector push_back would be much better Using std::list would also be better

Does this ring a bell with anyone?

[MiiNiPaa]

for optimization on gcc you should use -O2, -DNDEBUG and other options.

[Lowest0ne]

It's not those. It's like a profiler, but when you run the program it considers alternative methods/containers that would help the program. It also displays a percentage gain over the current setup.

[MiiNiPaa]

gcc usually goes hand to hand with gdb and gprof which are debugger and profiler respectivelly. I did not heard about anything similar and even static code analysers are not that good.

Also in your code inset cannot be replaced by push_back because it would change code semantics.

[Little Bobby Tables]

http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

__optimize__ maybe?

[MiiNiPaa]

They are not changing anything in compilator behavior. It is defined be compiler depending on flags so your preprocessing code can detect them and maybe change code depending on that.

[TwilightSpectre]

In a couple of tutorials for OpenGL I have seen something similar, so I know what you are talking about. I don't know for GCC, but for VS at least some examples are using macros for the <math.h> functions rather than functions, and removing bounds checking on the STL [] operators.

[MrHutch]

NT3 wrote:

removing bounds checking on the STL [] operators

I was under the impression that STL [] operators didn't have bounds checking, unlike the at() methods.

[long double main]

Lowest0ne wrote:

Does this ring a bell with anyone?

I think I've seen something like that before -- it looks VERY familiar.

Google's not helping me out here, though....

[Lowest0ne]

long double main wrote:

Google's not helping me out here, though....

Yeah, I feel like I saw it within the libstd docs on my machine.

Edit: Yep, found it:

$ cat foo.cc
#include <vector>
int main() {
  std::vector<int> v;
  for (int k = 0; k < 1024; ++k) v.insert(v.begin(), k);
}

$ g++ -D_GLIBCXX_PROFILE foo.cc
$ ./a.out
$ cat libstdcxx-profile.txt
vector-to-list: improvement = 5: call stack = 0x804842c ...
    : advice = change std::vector to std::list
vector-size: improvement = 3: call stack = 0x804842c ...
    : advice = change initial container size from 0 to 1024

And if you're looking for it, I found it here:
/usr/share/doc/gcc-4.8-base/libstdc++/html/manual/profile_mode.html

[MiiNiPaa]

change std::vector to std::list

Useless advice mode. YOu should just reverse your loop and add to the end. Or use deque.

[htirwin]

#include <vector>

int main( void )
{
  std::vector< int > numbers;
  for ( int i = 0; i < 100; ++i )
    numbers.insert( numbers.begin(), i );

  return 0;
}

You should just reverse your loop and add to the end. Or use deque.

Also useless advice. The correct way to fully optimize this program would by to modify it to the following:

int main( void )
{
  return 0;
}

Jokes aside, if it can tell you how something can be improved that you didn't notice then it's not useless; even if you find a better solution yourself after it brings it to your attention.

[TwilightSpectre]

@iHutch
Yes, that should be correct. However, for some reason, MSVS gives some sort of bounds checking for the [] operators in Debug mode, as can be seen here (2010 Vector):

    const_reference operator[](size_type _Pos) const
        {    // subscript nonmutable sequence
 #if _ITERATOR_DEBUG_LEVEL == 2
        if (size() <= _Pos)
            {    // report error
            _DEBUG_ERROR("vector subscript out of range");
            _SCL_SECURE_OUT_OF_RANGE;
            }

 #elif _ITERATOR_DEBUG_LEVEL == 1
        _SCL_SECURE_VALIDATE_RANGE(_Pos < size());
 #endif /* _ITERATOR_DEBUG_LEVEL */

        return (*(this->_Myfirst + _Pos));
        }

There is some macro you can set to disable the _SCL_SECURE thingies.

[ne555]

the keyword is debug mode

there is also for gcc, if you define the _GLIBCXX_DEBUG macro