Strange Growth of Executables

Discussion in 'C++' started by Mike Copeland, Jun 3, 2013.

  1. I've encountered a strange (to me) situation as I migrate a lot of C-
    based code to C++ code and structures. (Using VS10 Express.)
    Specifically, as I convert large data arrays (both structures and POD
    arrays) to vectors, the executable files grow and grow (!). Once I
    change one array to a vector (and accept the STL runtime expansion), I
    would expect that changing more data in the same program would, at
    worst, keep the executable size static. At best, I had hoped the
    programs would shrink...because allocating large data areas (e.g. int
    [60000] -> vector{int>) would produce less code and smaller executables.
    In fact, the opposite of my expectations occurs: the more I change,
    the larger the programs grow (no other changes or functionality mods).
    This really surprises me, as I had thought STL code would be smaller
    and more efficient... 8<{{
    Any thoughts on this? TIA
    Mike Copeland, Jun 3, 2013
    #1
    1. Advertising

  2. Mike Copeland

    red floyd Guest

    On 6/3/2013 2:50 PM, Mike Copeland wrote:
    > I've encountered a strange (to me) situation as I migrate a lot of C-
    > based code to C++ code and structures. (Using VS10 Express.)
    > Specifically, as I convert large data arrays (both structures and POD
    > arrays) to vectors, the executable files grow and grow (!). Once I
    > change one array to a vector (and accept the STL runtime expansion), I
    > would expect that changing more data in the same program would, at
    > worst, keep the executable size static. At best, I had hoped the
    > programs would shrink...because allocating large data areas (e.g. int
    > [60000] -> vector{int>) would produce less code and smaller executables.
    > In fact, the opposite of my expectations occurs: the more I change,
    > the larger the programs grow (no other changes or functionality mods).
    > This really surprises me, as I had thought STL code would be smaller
    > and more efficient... 8<{{
    > Any thoughts on this? TIA
    >


    Are you sure that you're not seeing debug/symbol info growing? Have
    you done anything to measure code/data size?

    The size of an EXE is a matter of many thing, of which code/data are
    a small part.
    red floyd, Jun 4, 2013
    #2
    1. Advertising

  3. Mike Copeland

    Öö Tiib Guest

    On Tuesday, 4 June 2013 00:50:00 UTC+3, Mike Copeland wrote:
    > I've encountered a strange (to me) situation as I migrate a lot of C-
    > based code to C++ code and structures. (Using VS10 Express.)
    > Specifically, as I convert large data arrays (both structures and POD
    > arrays) to vectors, the executable files grow and grow (!). Once I
    > change one array to a vector (and accept the STL runtime expansion), I
    > would expect that changing more data in the same program would, at
    > worst, keep the executable size static. At best, I had hoped the
    > programs would shrink...because allocating large data areas (e.g. int
    > [60000] -> vector{int>) would produce less code and smaller executables.
    > In fact, the opposite of my expectations occurs: the more I change,
    > the larger the programs grow (no other changes or functionality mods).
    > This really surprises me, as I had thought STL code would be smaller
    > and more efficient... 8<{{
    > Any thoughts on this? TIA


    Thoughts are such:

    1) VS2010 contains experimental compiler that compiles something that is not
    C++03 nor C++11.

    2) 'std::vector' is dynamic array. Dynamic array you get with
    'int* array = malloc(60000*sizeof(int))' in C.

    3) 'std::array' is static array and 'int[60000]' is 'std::array<int,60000>'

    4) When code defines 'int massive[60000] = {0};' then that does not mean that the
    executable will contain 240000 '\0' bytes somewhere as result.

    5) You likely measure debug builds.

    6) STL contains no magic. Usage of raw static array in C produces about as
    compact code as it can get. STL containers are usually safer and often as compact.

    7) Mechanically translating by hand from one language to other usually results with
    defects and inefficiency.
    Öö Tiib, Jun 4, 2013
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Generic Usenet Account

    Tracking the "memory growth" of a process

    Generic Usenet Account, Apr 5, 2004, in forum: C++
    Replies:
    5
    Views:
    455
    Kevin Goodsell
    Apr 6, 2004
  2. Generic Usenet Account

    Tracking the "memory growth" of a process

    Generic Usenet Account, Apr 5, 2004, in forum: C Programming
    Replies:
    4
    Views:
    328
    Kevin Goodsell
    Apr 6, 2004
  3. sam
    Replies:
    3
    Views:
    357
    Kent Johnson
    Mar 19, 2005
  4. Denis Palas
    Replies:
    1
    Views:
    486
  5. Juha Nieminen
    Replies:
    3
    Views:
    341
    Stuart
    Sep 21, 2012
Loading...

Share This Page