On Thu, Sep 26, 2013 at 3:05 PM, Sam Putman <[email protected]> wrote:
> > > > On Thu, Sep 26, 2013 at 2:31 PM, David Barbour <[email protected]>wrote: > >> >> On Thu, Sep 26, 2013 at 11:58 AM, Sam Putman <[email protected]>wrote: >> >>> >>> >>>> How often do we compare very large integers for equality? >>>> >>>> >>> Rather often, and still less than we should. Git does this routinely, >>> and Datomic revolves around it. The lower-level the capability is built in, >>> the more often, in general, we can benefit from it. >>> >> >> In incremental systems, there is a tradeoff between recomputing vs. >> caching. At too fine a granularity, caching can be orders of magnitude >> worse than recomputing, due to the extra memory and branching overheads. At >> too coarse a granularity, recomputing can be orders of magnitude worse. >> More of a good thing can be a bad thing. This is made more complicated when >> different substructures update at different frequencies, or in different >> bursts, or with various feedback properties. In general, there are no easy >> answers (other than "profile!") when it comes to optimizing performance. >> > > It's less about performance, per se, as it is about making certain actions > easy. In Datomic, for example, one may request a hash that represents the > complete state of a database at any given point in time, and then query > that database using that hash. This is a pretty good trick. It's also > difficult to imagine a globally distributed cache that didn't in some > fashion follow this principle. > Use of a hash to identify states in a large persistent data structure is indeed a nice trick. I can see the appeal of centralizing information about update over time. I do not find it difficult to think of alternatives, though, such as keeping timestamps all-the-way down. The latter approach weakens global serializability and offers greater expressiveness. These properties can be leveraged for speculative evaluation or open systems integration. Anyhow, at this time I feel hashes should be used explicitly, and have relatively specialized use-cases.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
