New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Command-line decoding is slower in 3.0w for large inputs, flag settings #95

Closed
GoogleCodeExporter opened this Issue Mar 24, 2015 · 1 comment

Comments

Projects
None yet
1 participant
@GoogleCodeExporter

GoogleCodeExporter commented Mar 24, 2015

This is a bug in the command-line tool.

I changed (somewhat) the algorithm for caching source-data blocks, in order 
to support streaming source files.  You aren't using a streaming source, so 
this should not have happened.  I'll fix ASAP.

For now, you can raise -B.  See if giving it another 10% solves the 
problem.  If that works, it'll mean there's a boundary condition error 
somewhere.  If you run with three or four -v's it will print source-block 
evictions as they happen, you'll notice quickly.

I'll address this two ways: (1) print a warning when the source-I/O is 
performing badly (suggesting to raise -B), (2) the encoder/decoder should 
not become source-I/O-bound when they use the same -B setting, I'll add a 
test to verify this.

Original issue reported on code.google.com by josh.mac...@gmail.com on 7 Nov 2009 at 2:55

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 24, 2015

SVN 310

Original comment by josh.mac...@gmail.com on 16 Feb 2010 at 5:44

  • Changed state: Fixed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment