0

I am taking part in programming contests using C++.As is known to all,those contests have strict limits on execution time,and allocating from heap using malloc or new is slow,so I tried overloading operator new in my program.

It worked fine,until today I was trying to solve a problem which requires about 700MB memory,I submitted on the online judge and got an complie error:Compiled file is too large

Then I checked my local .exe file,and shocked to find that it's about 30MB!!

After debugging for a long time,I found the cause:I declared a static array inside operator new,and it seems that the size of the .exe file varies to the size of that array!!!! Here is my testing code:

#include <cstdlib>
const int MAXN=1e6;
struct A {
    int x;
    void *operator new(size_t) {
        static char Pool[MAXN*sizeof(A)];
        //static A Pool[MAXN];
        //static A *Pool=(A*)calloc(MAXN,sizeof(A));
        static A *Me=(A*)Pool;
        return Me++;
    }
};
int main() {
    A *null=new A;
    return 0;
}

the .exe size increases as the MAXN increases. Can anyone explain this to me? Thanks in advance ^_^

Environment:

Windows 7 x32

TDM-GCC 5.1.0

Lucida
  • 1
  • 2
    *Can anyone explain this to me?* -- Where do you think that array is going to be stored? -- *As is known to all,those contests have strict limits on execution time* -- Those limits are overcome by using better algorithms, not by trying to tweak a compiler here or there. Overloading `operator new` was totally unnecessary. – PaulMcKenzie Apr 25 '17 at 08:43
  • 1
    [Handling of static arrays during compile-time](http://stackoverflow.com/questions/21350478/what-does-memory-allocated-at-compile-time-really-mean) – v78 Apr 25 '17 at 08:49
  • Even if using the same algorithm,the execution time differs depending on the implementation.Not all the judging computers runs fast as Codeforces',and in China,most of the contests even don't add `-O2` while compiling.Thanks for your answer.I really didn't know where the array is to be stored. – Lucida Apr 25 '17 at 08:58
  • 1
    *most of the contests even don't add -O2 while compiling* -- Then these contests are a waste of time. Complain to the sites. – PaulMcKenzie Apr 25 '17 at 09:12
  • 1
    ... or stop with this "competitive [broken] programming" nonsense and instead practice getting good at writing _real_ software. – Lightness Races in Orbit Apr 25 '17 at 09:13

1 Answers1

1

What's to explain? You said you wanted to avoid taking memory from the target machine's free store, and that's exactly what you've done — the memory is now found in the static data area of your program instead. The only other place to go would be "the stack", which is typically far too small for this amount of data. Basically, this is what happens when you try to go against conventional wisdom.

It was completely pointless anyway; sure, there's a small amount of overhead in dynamic allocation, but a small amount that will not tax a modern system. If you need to allocate 700MB in one go, that will not take more time than allocating 1MB. So just do it.

If you need to allocate 700MB in lots of little pieces then you may have a reason to use a pre-allocated memory pool, but that can still come from new.

The real way to beat "strict execution time limits" in competitive programming is not through "tricks", but through writing an efficient algorithm that scales at the proper rate and does not perform needless data copies everywhere. Or, better yet, stop with this "competitive [broken] programming" and instead practice getting good at writing real software... with the optimisation switches turned on.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • I appreciate your suggestion.Thank you.But I am still confused.I didn't give an initial value,so why this increases my `.exe` file size? – Lucida Apr 25 '17 at 09:26
  • I ran more tests,and the increase of the size of `.exe`file only happens when I overload a struct member operator new,and doesn't happen when I overload the global operator new.Why is this? – Lucida Apr 25 '17 at 09:32
  • @Lucida: I don't know, and it doesn't matter! – Lightness Races in Orbit Apr 25 '17 at 09:42