todo/tahoe lfs for realsgit-annexhttp://git-annex.branchable.com/todo/tahoe_lfs_for_reals/git-annexikiwiki2013-11-27T22:47:37Zperformancehttp://git-annex.branchable.com/todo/tahoe_lfs_for_reals/comment_1_0a4793ce6a867638f6e510e71dd4bb44/zooko2013-11-27T22:47:37Z2011-05-17T19:20:39Z
<p>Hm... O(N<sup>2</sup>)? I think it just takes O(N). To read an entry out of a directory you have to download the entire directory (and store it in RAM and parse it). The constants are basically "too big to be good but not big enough to be prohibitive", I think. jctang has reported that his special remote hook performs well enough to use, but it would be nice if it were faster.</p>
<p>The Tahoe-LAFS folks are working on speeding up mutable files, by the way, after which we would be able to speed up directories.</p>
comment 2http://git-annex.branchable.com/todo/tahoe_lfs_for_reals/comment_2_80b9e848edfdc7be21baab7d0cef0e3a/joey2013-11-27T22:47:37Z2011-05-17T19:57:33Z
<p>Whoops! You'd only told me O(N) twice before..</p>
<p>So this is not too high priority. I think I would like to get the per-remote storage sorted out anyway, since probably it will be the thing needed to convert the URL backend into a special remote, which would then allow ripping out the otherwise unused pluggable backend infrastructure.</p>
<p>Update: Per-remote storage is now sorted out, so this could be implemented
if it actually made sense to do so.</p>