Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Coffee corner » Some Experiment with Size of Upp Executable (Mostly some fun facts.)
Re: Some Experiment with Size of Upp Executable [message #57887 is a reply to message #57886] Mon, 27 December 2021 05:28 Go to previous messageGo to previous message
Lance is currently offline  Lance
Messages: 656
Registered: March 2007
Contributor
Obviously *.t(s) don't contribute too much to the size of the final executables of empty U++ projects.

Question: who contribute(s) most? In a CtrlLib, we expect all *.iml files do a part. What about the plain Core console application?

Anyway, some more relevant/irrelevant tests.
Test 3: How well compilers optimize out unused code.
A common nonsense function used by both scenarios which will potentially increase the sizes of final executables by noticeable amounts.
int BigFunction(int i)
{
	static const char * s[]={R"(
#include "CtrlCore.h"

namespace Upp {

#define LTIMING(x)

ImageBuffer::ImageBuffer(ImageDraw& iw)
{
	Image m = iw;
	Set(m);
}

// more omitted. basically I take a file, paste it
// multiple times, encode each in R"( )", and create an
// const char* array[].
)",R"(....)"};

	int sum=0;
	for(int j=0; j<(int)strlen(s[i]); ++j)
		sum+=s[i][j];
	return sum;
}

Senario 1
#include <Core/Core.h>

using namespace Upp;

int BigFunction(int i);

CONSOLE_APP_MAIN
{
	RLOG(BigFunction(Upp::Random()%7));
}

Senario 2: With reference to BigFunction commented out.
#include <Core/Core.h>

using namespace Upp;

int BigFunction(int i);

CONSOLE_APP_MAIN
{
//	RLOG(BigFunction(Upp::Random()%7));
}

Senario 3
In senario 3, I changed the BigFunction so that the const char * s[]; is move out of the function body, with or without the static modifier. Senario 3 is otherwise same as Senario 1, with invocation of BigFunction commented out.

Test result
			NoBigFun  Sen.2	  Sen.1	  Sen.3
// MSBT22x64 Release	 767488	 767488	 770560	 769024
// MSBT22 Release	 644608	 644608	 648192	 646144
// CLANGx64 Release	1725952	1727488	1728512	1727488
// CLANG  Release	1849856	1852928	1853440	1852416

Conclusion: In this test, CLANG performed very poorly. However, MS Build Tools (almost) did exactly what's expected: simply including the definition of a function without invoking it should have no impact on the sizes of final executables. As long as one compiler can do that, we expect others (eg. CLANG) to catch up in the future.

And It makes sense to encapsulate big objects in functions.

Out of random search of U++ code, I noticed that mirek actually did very well on this. Some other code could potentially benefit from this kind of audit:
#include "SDL2GL.h"

namespace Upp {

const static VectorMap<dword, dword> SDL_key_map = {
//	{ SDLK_BACKSPACE, K_BACK        },
	{ SDLK_BACKSPACE, K_BACKSPACE   },
	{ SDLK_TAB,       K_TAB         },
	{ SDLK_SPACE,     K_SPACE       },
	{ SDLK_RETURN,    K_RETURN      },

	{ SDLK_LSHIFT,   K_SHIFT_KEY    },
	{ SDLK_LCTRL,    K_CTRL_KEY     },
	{ SDLK_LALT,     K_ALT_KEY      },
	{ SDLK_CAPSLOCK, K_CAPSLOCK     },
	{ SDLK_ESCAPE,   K_ESCAPE       },
	{ SDLK_PAGEUP,   K_PAGEUP       },
	{ SDLK_PAGEDOWN, K_PAGEDOWN     },
	{ SDLK_END,      K_END          },
	{ SDLK_HOME,     K_HOME         },
	{ SDLK_LEFT,     K_LEFT         },
	{ SDLK_UP,       K_UP           },
	{ SDLK_RIGHT,    K_RIGHT        },
	{ SDLK_DOWN,     K_DOWN         },
	{ SDLK_INSERT,   K_INSERT       },
	{ SDLK_DELETE,   K_DELETE       },

	{ SDLK_KP_0, K_NUMPAD0 },
	{ SDLK_KP_1, K_NUMPAD1 },
	{ SDLK_KP_2, K_NUMPAD2 },
	{ SDLK_KP_3, K_NUMPAD3 },
	{ SDLK_KP_4, K_NUMPAD4 },
	{ SDLK_KP_5, K_NUMPAD5 },
	{ SDLK_KP_6, K_NUMPAD6 },
	{ SDLK_KP_7, K_NUMPAD7 },
	{ SDLK_KP_8, K_NUMPAD8 },
	{ SDLK_KP_9, K_NUMPAD9 },
	{ SDLK_KP_MULTIPLY, K_MULTIPLY  },
	{ SDLK_KP_PLUS,     K_ADD       },
	{ SDLK_KP_PERIOD,   K_SEPARATOR },
	{ SDLK_KP_MINUS,    K_SUBTRACT  },
	{ SDLK_KP_PERIOD,   K_DECIMAL   },
	{ SDLK_KP_DIVIDE,   K_DIVIDE    },
	{ SDLK_SCROLLLOCK,  K_SCROLL    },
	{ SDLK_KP_ENTER,    K_ENTER     },
	
	{ SDLK_F1,  K_F1  },
	{ SDLK_F2,  K_F2  },
	{ SDLK_F3,  K_F3  },
	{ SDLK_F4,  K_F4  },
	{ SDLK_F5,  K_F5  },
	{ SDLK_F6,  K_F6  },
	{ SDLK_F7,  K_F7  },
	{ SDLK_F8,  K_F8  },
	{ SDLK_F9,  K_F9  },
	{ SDLK_F10, K_F10 },
	{ SDLK_F11, K_F11 },
	{ SDLK_F12, K_F12 },

	{ SDLK_a, K_A },
	{ SDLK_b, K_B },
	{ SDLK_c, K_C },
	{ SDLK_d, K_D },
	{ SDLK_e, K_E },
	{ SDLK_f, K_F },
	{ SDLK_g, K_G },
	{ SDLK_h, K_H },
	{ SDLK_i, K_I },
	{ SDLK_j, K_J },
	{ SDLK_k, K_K },
	{ SDLK_l, K_L },
	{ SDLK_m, K_M },
	{ SDLK_n, K_N },
	{ SDLK_o, K_O },
	{ SDLK_p, K_P },
	{ SDLK_q, K_Q },
	{ SDLK_r, K_R },
	{ SDLK_s, K_S },
	{ SDLK_t, K_T },
	{ SDLK_u, K_U },
	{ SDLK_v, K_V },
	{ SDLK_w, K_W },
	{ SDLK_x, K_X },
	{ SDLK_y, K_Y },
	{ SDLK_z, K_Z },
	{ SDLK_0, K_0 },
	{ SDLK_1, K_1 },
	{ SDLK_2, K_2 },
	{ SDLK_3, K_3 },
	{ SDLK_4, K_4 },
	{ SDLK_5, K_5 },
	{ SDLK_6, K_6 },
	{ SDLK_7, K_7 },
	{ SDLK_8, K_8 },
	{ SDLK_9, K_9 },

	{ K_CTRL|219,  K_CTRL_LBRACKET   },
	{ K_CTRL|221,  K_CTRL_RBRACKET   },
	{ K_CTRL|0xbd, K_CTRL_MINUS      },
	{ K_CTRL|0xc0, K_CTRL_GRAVE      },
	{ K_CTRL|0xbf, K_CTRL_SLASH      },
	{ K_CTRL|0xdc, K_CTRL_BACKSLASH  },
	{ K_CTRL|0xbc, K_CTRL_COMMA      },
	{ K_CTRL|0xbe, K_CTRL_PERIOD     },
	{ K_CTRL|0xbe, K_CTRL_SEMICOLON  },
	{ K_CTRL|0xbb, K_CTRL_EQUAL      },
	{ K_CTRL|0xde, K_CTRL_APOSTROPHE },

	{ SDLK_PAUSE, K_BREAK }, // Is it really?

	{ SDLK_PLUS,      K_PLUS      },
	{ SDLK_MINUS,     K_MINUS     },
	{ SDLK_COMMA,     K_COMMA     },
	{ SDLK_PERIOD,    K_PERIOD    },
	{ SDLK_SEMICOLON, K_SEMICOLON },

	{ SDLK_SLASH,        K_SLASH     },
	{ SDLK_CARET,        K_GRAVE     },
	{ SDLK_LEFTBRACKET,  K_LBRACKET  },
	{ SDLK_BACKSLASH,    K_BACKSLASH },
	{ SDLK_RIGHTBRACKET, K_RBRACKET  },
	{ SDLK_QUOTEDBL,     K_QUOTEDBL  }
};


Majority of the occurrences seem to be from plugin(wrapping of c source libraries). These are quite difficult to fix without actually touch the imported source codes. Ideally a parser should be created to automate the job if it's decided to be of significant savings.
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Quiz #2
Next Topic: Quiz #5
Goto Forum:
  


Current Time: Sun Aug 24 21:15:07 CEST 2025

Total time taken to generate the page: 0.04667 seconds