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


Ignore:
Timestamp:
Dec 5, 2007 1:19:31 PM (6 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