Recall that a spiff is code added to the DBMS source that, given values of invariants known in cold code, generate specialized code (termed “speccode”) that will be called in hot code when the query is executed. How big are they?
There are several senses of “how big” that are important.
The first is the amount of original code that is specialized by each spiff. In our experience over trials on four proprietary DBMSes and four open-source DBMSes, that the code to be specialized by each spiff ranges from a dozen to two hundred lines of code.
The second metric is the size of the spiff itself: the code that generates the speccode, given the values of the invariants. Roughly speaking, a spiff is an annotated version of the code to be specialized. The spiffs simply add annotations that describe how the optimized source code is generated given invariant(s) known at runtime(Note that the annotated version becomes a component of the source code.)
The third metric is the number of calls to the Spiff Runtime Environment (SRE) to be added to the DBMS source code. Each specialization requires just a few calls to the SRE, to prepare and set up the specialized code for execution, at carefully-chosen places within the DBMS source.
The high-order bit is that spiffs (and the auxiliary code to support them) are small, relative to all other available approaches that can significantly increase the performance of a complex DBMS. This nimbleness allows field specialization to be applied rapidly and aggressively, improving application performance without sacrificing the maintainability of the code.