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.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
