 in computer science, a spaceâtime or timeâmemory tradeoff is a situation where the memory use can be reduced at the cost of slower program execution (and, conversely, the computation time can be reduced at the cost of increased memory use). as the relative costs of cpu cycles, ram space, and hard drive space changeâhard drive space has for some time been getting cheaper at a much faster rate than other components of computersâthe appropriate choices for spaceâtime tradeoffs have changed radically. often, by exploiting a spaceâtime tradeoff, a program can be made to run much faster. ==history== the basic idea of timeâmemory tradeoff goes back to the earliest time of evolution, since basically using knowledge instead of brute-force trials, and encoding reflex reactions in the dna to avoid the organism to have to "calculate", i.e., think how to react, in time-critical situations, are examples of this. more specifically to the use in computers, look-up tables (and in particular, e.g., storing coefficients of power series for transcendental functions) have been implemented since the very earliest operating systems. in 1980 martin hellman first proposed using a timeâmemory tradeoff for cryptanalysis. ==types of tradeoff== ===lookup tables vs. recalculation=== the most common situation is an algorithm involving a lookup table: an implementation can include the entire table, which reduces computing time, but increases the amount of memory needed, or it can compute table entries as needed, increasing computing time, but reducing memory requirements. ===compressed vs. uncompressed data=== a spaceâtime tradeoff can be applied to the problem of data storage. if data is stored uncompressed, it takes more space but less time than if the data were stored compressed (since compressing the data reduces the amount of space it takes, but it takes time to run the decompression algorithm). depending on the particular instance of the problem, either way is practical. there are also rare instances where it is possible to directly work with compressed data, such as in the case of compressed bitmap indices, where it is faster to work with compression than without compression. ===re-rendering vs. stored images=== storing only the latex source and rendering it as an image every time the page is requested would be trading time for space; more time used, but less space. rendering the image when the page is changed and storing the rendered images would be tradin
Software_optimization