Application footprint
In computing, footprint of an application software (or application footprint) provides a sense of sizing of its various constituents, and hence, is a spatial measurement, in a given context, such as disk footprint, memory footprint (a.k.a. runtime footprint), network footprint, etc. In each case, footprint of an application excludes data that it may operate on, as part of storage or execution, but essentially includes programs (executable and libraries), configuration files, resources (binary or textual) and other context-specific components that may be considered as part of the software.
Whereas disk footprint of an application refers to its storage size, runtime footprint translates to memory requirements at execution time. Network footprint, on the other hand, refers to the extent of control information that a network-based application references, again, excluding any data that it may require to transmit (download or upload) to carry its activities. For example, the network footprint of an application that fetches execution logs from a server does not include the sizes of logs it would have fetched in a typical session, but would include control messages that it would have sent and received.
Distinguishing Disk Footprint Vs. Memory Footprint
Often, disk footprint is confused with memory footprint, since both include certain overlapping areas, such program executable, libraries, etc. Though this is true to a certain extent, their individual makeup contain areas that are not relevant or clearly correspond to anything in the other category. For example, runtime footprint of an application would include stack space, which is typically meaningless in the storage footprint paradigm. On the other hand, configuration files read-in by an application, at start up, are usually closed off, but their in-memory representation (such as a property tree or linked list of key-value pairs) maintained for its entire life-time, and hence, do not really correspond, in terms of relative sizing. Further, the configurations read-in from differing formats (say XML, JSON, CSVs, etc.), may contribute to differing disk sizing, but end up being represented as the same internal data structures, ending up in similar, if not identical, memory sizing requirements.
See also
References
 |  |
