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. I think the same applies here. Building this feature in at a lower level does not mean you'll benefit from it. > > a tacit concatenative language would have 'words' in the Forth sense, > making those words the nodes of the tree would make defining a consistent > tree hash at least approachable. Doing this for arbitrary structured data > would greatly reward a consistent approach to defining and parsing > structured/typed data, which is likely another digression. > It seems to me that this would encourage a much more rigid PX/UX in order to satisfy the whims of Merkle.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
