On Thu, Jan 8, 2015 at 3:32 PM, Joerg Sonnenberger <jo...@britannica.bec.de> wrote: > On Thu, Jan 08, 2015 at 03:21:07PM -0800, bch wrote: >> The mtime/stat(2) stress is expensive because it's a order(n) >> operation, but better than any other validation (checksumming) method >> -- is git not subject to similar performance hits ? Does it have a >> diff't method to verify integrity, or does it punt on that front >> because of guarantees from elsewhere, or a different requirements ? > > You can't really avoid the O(n) hit without using a background monitor > or the like. My point is that table update is done in such a bad manner, > that the *constant* factor is extremely high. In other words, you want > to update to a version with m changed files for a working copy with n > files, the write cost should be O(m), but it is O(n).
Ok, is that something which can be fixed by rewriting key pieces of SQL and/or C ? I.e. the command implementation would have to detect the unchanged files on update and skip them. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
