Changes between Version 9 and Version 10 of Commentary/Compiler/RecompilationAvoidance


Ignore:
Timestamp:
Dec 5, 2007 1:19:31 PM (8 years ago)
Author:
simonmar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/RecompilationAvoidance

    v9 v10  
    312312== Alternative design choices ==
    313313
    314 === fingerprints instead of versions ===
    315 
    316 === module-granularity instead of declaration-granularity ===
     314=== Fingerprints instead of versions ===
     315
     316Version numbers in this context have a couple of problems:
     317
     318 * New version numbers are calculated from the old version numbers, so we have to
     319   keep the old interface around to generate the new one.  (but we need to keep
     320   the old interface around anyway, because we might avoid touching it if it
     321   doesn't change).
     322
     323 * Removing an interface file can have disastrous effects, as all its version
     324   numbers will be reset when it is next compiled.  To be fair, this doesn't seem
     325   to affect many people (that we know of).
     326
     327 * We want to detect changes in package dependencies (see #1372): right now, we only
     328   record a dependency on the package.  The right thing to do is to record a dependency
     329   on the module that we import, so we can detect when it changes.  But packages are
     330   generally compiled from scratch and then installed, so typically all the version
     331   numbers will be 1, and our dependency is not telling us when the package has changed.
     332
     333Using fingerprints or hashes instead of version numbers is morally the right thing to do.  A fingerprint can be calculated independently of the previous version of the interface interface, and it solves the package dependency problem.
     334
     335=== Module-granularity instead of entity-granularity ===
     336
     337Fingerprints or hashes are larger than version numbers (typically 128 bits instead of 32), so we might not want to put a fingerprint on every entity.
     338
     339Also, it's worth thinking about whether tracking changes at a lower level of granularity would result in a system that is simpler to implement, understand, and get right.  The obvious choice is to track modules instead of entities.  Clearly this loses some resolution, and will therefore entail more unnecessary recompilation, but how much?  Let's look at how it would work, and then some examples.
     340
     341Every module will have a single version number (or fingerprint), which is increased whenever there is a change to either the exports or the decls (but not the usages) in the interface, or the version of any module referred to by the exports or decls changes.  The usages of the module lists the modules and versions referred to by the source code (as before, except that we only record modules not entities).
     342
     343'''Examples'''.
     344