[Xapian-tickets] [Xapian] #325: flint_table.cc uses zlib inefficiently

Xapian nobody at xapian.org
Tue Feb 17 05:17:20 GMT 2009

#325: flint_table.cc uses zlib inefficiently
 Reporter:  tlipcon        |        Owner:  richard  
     Type:  enhancement    |       Status:  new      
 Priority:  normal         |    Milestone:  1.1.0    
Component:  Backend-Flint  |      Version:  SVN trunk
 Severity:  normal         |   Resolution:           
 Keywords:                 |    Blockedby:           
 Platform:  All            |     Blocking:           
Changes (by olly):

  * owner:  olly => richard


 Assigning to Richard as he seems to be working actively on this.

 Comments on the latest patch (I only looked at the trunk one, but we
 should certainly consider backporting if this looks good on trunk as it
 sounds like it can make quite a difference on some platforms):

 Don't forget to thank Todd in AUTHORS!

 As above, the destructor doesn't need to be virtual.

 I think this comment is still helpful and should be kept:

             // Deflate failed - presumably the data wasn't compressible.

 I wouldn't worry about errors from {{{inflateEnd()}}} and
 {{{deflateEnd()}}} - we already check for problems which matter at the
 time and in the current code an error in either calls {{{abort()}}} (or is
 ignored when expected).  I'd say just cast the return values to
 {{{(void)}}} to make it clear this is deliberate.

 The two new methods really ought to have doc comments, and the new zstream
 pointer members probably should get one each.

 I wonder if the laziness is worthwhile - we could just initialise these
 for a compressed table up front.  They could even be members rather than
 pointers, but that's a fair overhead for a non-compressed table.  I don't
 have a problem with the approach here though - just wondering aloud

Ticket URL: <http://trac.xapian.org/ticket/325#comment:5>
Xapian <http://xapian.org/>

More information about the Xapian-tickets mailing list