Optimizing a vector loop

Educated guesses are: in this case, loop unrolling will probably feature in a big way, and may account for most of the 20X improvement. Additionally, with the loop unroll it may make other things like instruction-level-parallelism more effective, and even cache-line management.

There are essentially only two comments to make on your situation:

1. non-optimized code is going to be slower.... you pay money for the compiler for a reason, lots of smart people make it 'go fast'.
2. you need to inspect the instruction-level code (asm) generated by the compiler in order to understand the main differences between the two versions ... anything else is just educated guessing.

Edit

FWIW, Purely for interest sake.... , you may want to try to manually unroll your inner-most loop, and see if this makes a significant difference:

        for (auto it = units.begin() + n; it != (units.begin() + (n + j + 1)); it++)
        {
            sizesMap[1] += (*it).sizes[1];
            sizesMap[2] += (*it).sizes[2];
            sizesMap[3] += (*it).sizes[3];
            sizesMap[4] += (*it).sizes[4];
            sizesMap[5] += (*it).sizes[5];
            sizesMap[6] += (*it).sizes[6];
            sizesMap[7] += (*it).sizes[7];
            sizesMap[8] += (*it).sizes[8];
            sizesMap[9] += (*it).sizes[9];
            sizesMap[10] += (*it).sizes[10];
            sizesMap[11] += (*it).sizes[11];
        }

You declared sizesMap[11], but initialized it with 13 entries. If that works at all, it might be overwriting some neighbouring memory. You could simply write sizesMap[11] = { 0 }.

Your code would be easier to understand if you universally added n to j:

for (unsigned n = 1; n != units.size(); n++)
        for (unsigned j = n; j != units.size(); j++)
        {
            unsigned sizesMap[11] = { 0 };

            for (auto it = units.begin() + n; it != units.begin() + (j + 1); it++)
            {
                for (unsigned k = 1; k != 11; k++)
                {
                    sizesMap[k] += (*it).sizes[k];

                }
            }
            //do something with sizesmap
        }

It's also more idiomatic C++ to write:

for (auto i = units.begin() + 1; i != units.end(); ++i) {
    for (auto j = i; j != units.end(); ++j) {
        unsigned sizesMap[11] = { 0 };
        for (auto it = i; it != j + 1; ++it) {
            for (size_t k = 1; k != sizeof(sizesMap) / sizeof(sizesMap[0]); k++) {
                sizesMap[k] += it->sizes[k];
            }
        }
        //do something with sizesMap
    }
 }

Assuming that when you "do something with sizesMap", you don't overwrite any of its entries, you can build on top of the sizesMap you previously constructed.

 for (auto i = units.begin() + 1; i != units.end(); ++i) {
     unsigned sizesMap[11] = { 0 };
     for (auto j = i; j != units.end(); ++j) {
         for (size_t k = 1; k != sizeof(sizesMap) / sizeof(sizesMap[0]); k++) {
             sizesMap[k] += j->sizes[k];
         }
         //do something non-destructive with sizesMap
     }
 }

I think you could even go further:

 unsigned sizesMap[11] = { 0 };
 for (auto i = units.begin() + 1; i != units.end(); ++i) {
     for (auto j = i; j != units.end(); ++j) {
         for (size_t k = 1; k != sizeof(sizesMap) / sizeof(sizesMap[0]); k++) {
             sizesMap[k] += j->sizes[k];
         }
         //do something non-destructive with sizesMap
     }
     for (size_t k = 1; k != sizeof(sizesMap) / sizeof(sizesMap[0]); k++) {
         sizesMap[k] -= i->sizes[k];
     }
 }

Is the compiler doing all that for you automatically? It seems a bit freaky that it could be smart enough to do so. The only way to tell what the optimizer is doing is to inspect its assembler output.