[jcifs] Re: Large File upload performance

[Michael B Allen]

> Anyway, I'm still surprised that a buffer copy could account for a 50%
> increase in the transfer time.

I think it probably could. If you're copying 8000 bytes in a for loop;
test, assign, test, assign, test, assign, ... then it's *at least* 16000
clock cycles literally down the tubes. By this metric writing a 32MB file
is an extra 64,000,000 clock cycles (unless System.arraycopy uses some
page table tricks but I doubt it).

Ideally, when encoding and decoding things it is better to have a function
(or method) that can accept an arbitrary array of data and then decode to
or encode from members of a struct (or object). That way you can just use
one buffer and pass it to the functions which will pass it on to
sub-functions and so on.

BTW, in case anyone's wondering *why* we copy when writing and not on
reading; the NbtSocket API write( byte[] b, int offset, int len ) method
accepts a byte[] array (b) that will be prefixed with the session service
NetBIOS header. You cannot write the 4 byte header and then the buffer
because the server could (and probably would) receive each in separate
packets. A well behaved server should accept this but I seriously doubt
they do. In C you could get around this problem using a writev or TCP_CORK
but Java has no such facility. We must allocate an array that is larger by
4 bytes, encode the NetBIOS header, append the data, and write to the
underlying socket in one operation. On the other hand, with read( byte[]
b, int offset, int len ) we don't have this problem because the NbtSocket
can read the NetBIOS header, decode it, and then read the rest directly
into the buffer we were given which is zero copy in user space.

Mike

-- 
A program should be written to  model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the  potential for it  to be applied  to tasks that are
conceptually similar and, more  important, to tasks that have not
yet been conceived.