Closed mscastanho closed 3 years ago
That's a good find. It appears we either forgot to put a return or a goto somewhere around that check. At the same time, I don't see any test on the flush parameter. If flush is set, no matter the size of input the inflate operation must be executed. I am wondering soft_copy_threshold=0 with lot of testing is the right way to go until then.
Fixed.
AFAIU,
fifo_in
onnx_inflate
is supposed to allow an optimization in which if the user provides too little data (less thansoft_copy_threshold
), the data can be buffered onfifo_in
and we can avoid the overhead of calling the NX engine, so inflate can return quickly to ask for more data.However, this does not seem to be happening right now. If the amount of availabe input data is less than the threshold, it's being copied to
fifo_in
alright, but the engine call is never being skipped, so we are actually just adding overhead by callingmemcpy
to copy data from the user's input buffer tofifo_in
.This becomes evident on
run_case2
ontest_inflate
. The test feeds libnxz with 1 byte of input at a time, so we should seefifo_in
buffering the input untilsoft_copy_threshold
is reached, with no calls to the NX engine before this point. But checking the logs for that test, looks like the engine is being called every time. I used this diff to generate the output below:Part of
nx.log
after running:NX_GZIP_LOGFILE=$(pwd)/nx.log NX_GZIP_VERBOSE=2 LD_LIBRARY_PATH=./lib/ ./test/test_inflate
Note that in the beginning
avail_in == 1 && avail_out > 0
, which ends up triggering the copy tofifo_in
(see thatused_in
becomes 1). And note that the engine is called nonetheless (note thatcall #N
is the same as for when we reach the threshold check, so that's still the samenx_inflate_
call).This same pattern is followed for subsequent bytes. The user keeps providing 1 byte of input with each call, and the NX engine is called for every single one of them, instead of buffering them for later for some batch processing.