[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
Comment:
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
really...
--
Ticket URL: <http://trac.xapian.org/ticket/325#comment:5>
Xapian <http://xapian.org/>
Xapian
More information about the Xapian-tickets
mailing list