The present disclosure relates to software optimization, and more particularly, to a method, apparatus, and computer program product for optimizing software symbol tables.
Software may include several modules, such as an executable file and a library which the executable file needs to invoke. Each module may include a number of symbols, e.g., functions and/or variables, which may include symbols defined by the module itself and used only by the module (which may be referred to as internal symbols hereinafter), symbols defined by the module itself and used by two or more modules and symbols defined by another module and used by two or more modules (the latter two types of symbols may be referred to as shared symbols hereinafter). Generally, a symbol table is established in each module to store all symbols in the module and information associated with the symbols, such as types of the symbols, absolute addresses and offsets of the symbols for positioning the symbols, and the like. When the module runs, the symbol table can be loaded, and a corresponding operation may be executed according to the symbols and the related information in the symbol table.
As the software becomes bigger and bigger, there are more and more symbols and related information in the symbol table, making the symbol table increasingly large. This leads to more time consumed to load and parse the symbol table when the software is executed, and thus reduces software execution efficiency. Conventionally, such a problem can be solved by two methods. In a first conventional method, a developer of the software manually analyzes source files of the respective modules of the software to identify all the shared symbols in the software, compiles an export file in which the shared symbols are labeled as “export”, and then provides the export file for a linker which hides the internal symbols in the symbol table of the module according to the export file. However, as the source files of the software are often very big in size, the operation of manually identifying all the shared symbols is very difficult and time-consuming, and is easy to cause omission. In addition, in the software (which, for example, is based on a C++ language), names of the symbols and the like may change during compiling and linking, rendering the method difficult to implement. In a second conventional method, the developer of the software modifies the source file of each module to add to the symbols in the module visibility labels indicating whether the symbols should be hidden, then the linker determines whether to hide the symbols in the symbol table according to the visibility labels of the symbols. This method requires modification of the source file, which would introduce additional risks, and when the software is updated, the labels of the respective symbols need to be updated accordingly, which is troublesome.
USPTO Backgrounds
USPTO Backgrounds