Optimize Executable Files (Modules) (Compact 2013)

3/26/2014

To save space in ROM, you may be able to rework some of your executable files, which you listed in the MODULES section of your .bib files. This task can be difficult to do for stability reasons. Also, because reworking executable files can involve making big changes to them, additional testing might be necessary.

Consider the following suggestions for reworking executable files:

• Separate your resources into a resource DLL. Moving the resources under .rsrc into a resource DLL provides several advantages. It enables you to compress the resource DLL, which can result in ROM usage reduction. It provides flexibility, such as for localization support, by enabling you to simply swap out resources for those built for different locales.
  Check your modules for resources by running the DUMPBIN Tool with the /headers option to display the file header and section headers. The information in the headers indicates the collective size of your code, data, and resources, in bytes. In the following example, the data size (.data section) is 0x005000 (20,480), the resource size (.rsrc section) is 0x01A000 (106,496), and the code size (.text section) is 0x0FA000 (1024000). Note that each section size is in multiples of 0x1000 (4096), which is the page size in ROM.

  dumpbin /headers <your module>
  
  Dump of file c:\WINCE800\release\MyDll.dll
  
  File Type: DLL
  
  Summary
  
          5000 .data
          C000 .pdata
         11000 .reloc
         1A000 .rsrc
         FA000 .text
  

• Remove redundant and unused code. Remove redundant and unused code from the executable file’s source code files, and then rebuild the executable file. For example, check for functions, variables, and parameters that are never used, all of which can make your code bigger and slower. Detect unused code by manual code review, a static code-analysis tool, or a code-coverage tool that can help identify suspected unused code.

• Avoid unnecessary floating-point arithmetic whenever possible. Floating-point calculations require the system to link to external libraries such as the Floating-Point Unit (FPU) support libraries or software emulation libraries (if no FPU is present in the system) to perform floating-point calculations. These calculations are slower and require additional code that the compiler generates.

• Avoid statically linked libraries. Static libraries often require duplicated code throughout your system, which results in a larger image size. When you use a statically linked library, you add object code to your module. Link to DLL files instead of pulling in code statically. Check your sources files and makefile files to make sure that you link to the correct library files.
  When the image contains dynamically linking libraries, the system is less likely to page out shared library code, which results in fewer page faults. In addition, files that load by using dynamically linked libraries automatically inherit changes to the libraries without recompiling or rebinding.

• Reorganize your code. Place constant tables or large data tables in a separate file from binary files. Add these files to the FILES section of your .bib file. Also, instead of allocating large amounts of static data in a module (data that you need to initialize), allocate memory for large read-write data at run time. If you do this, only the constants need to be in the data section within ROM.

See Also

Concepts

Optimize Modules and Files