[tahoe-lafs-trac-stream] [tahoe-lafs] #1543: rearrange share format to make downloads faster

[tahoe-lafs]

#1543: rearrange share format to make downloads faster
-------------------------------+-------------------------
     Reporter:  warner         |      Owner:
         Type:  enhancement    |     Status:  new
     Priority:  major          |  Milestone:  undecided
    Component:  code-encoding  |    Version:  1.9.0a1
   Resolution:                 |   Keywords:  performance
Launchpad Bug:                 |
-------------------------------+-------------------------

Comment (by zooko):

 Replying to [ticket:1543 warner]:
 >
 > Our current designs treat whole-file downloads and random-access as
 equal peers: we design first for minimum alacrity for the single-segment
 case. We could instead recognize that most downloads are whole-file, and
 accept a slight alacrity hit in exchange for faster throughput and higher
 transport efficiency

 Just for context about my thinking, I am generally not that keen on
 increasing performance for some usages while decreasing it for others,
 even if the former usages are more common. One thing that I don't like
 about that is that people may make assumptions about expected performance
 based on past observed performance, and if the performance is more
 ''consistent'' over different use cases, their assumptions are less wrong.

 This goes against a common (haha) engineering maxim of "optimize the
 common case". I think that maxim makes sense when a single user action is
 going to exercise a whole smorgasbord of different cases inside a system,
 so optimizing the most common of those internal cases results in a speedup
 for most or all possible user actions. But it is potentially problematic
 when different user actions exercise substantially different distributions
 of the internal cases.

 In this particular issue I'll bet it doesn't matter much since the fewer-
 round-trips and the scatter-gather-reads (the first two improvements that
 Brian mentioned) are probably the big issues, and improving them would
 probably not increase the performance gap between different usages.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1543#comment:1>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage