[jcifs] Peformance questions

[Philip Warner]

Hi,

For brevity, the summary is I have two questions regarding saving a file to a windows (Samba) share:
*
Q1: C**an I reduce the number of times it calls peekKey()?*
*Q2:  Is there any optimization that I can perform to reduce the DfsResolve() calls or cost?*


The background for these questions is below...

I am quite new to jCIFS. I recently added it to my Android app (Book Catalogue) and was surprised at how long it took to write data
to a network share via a WiFi link. I did some searches and found various references to setting buffer sizes as well as copying
data, but these did not seem to help (or explain the slowness completely).

For some numbers:

- save locally (sdcard) approx 1 minute (80mb file)
- save to network approx 5min 30sec (80mb file)
- copy file from local to network (using ES File Explorer), approx 1 min 30 (80mb file)

My next step was to profile the app. In a 29 second profiling session (much longer risks crashing either Android or the app), I found:

- 28,972ms total time
- 4007 ms total CPU (so it's spending 85% of its time waiting)
- of the total time, 53.7% (15571ms) is spent in SmbTransport.peekKey(). It was called a total of 337 times in the 29 seconds.

I assume that the peekKey() time is waiting for an ACK of some kind.

So the first question is:

*Q1: C**an I reduce the number of times it calls peekKey()?*

Once I ignore the peekKey() related calls (Transport.readn(), PlainSocketInputStream.read() etc), the next biggest time is:

- 7371ms in SmbFileOutputStream.writeDirect()

This does not worry me overly; it spends approx 26% of the total time writing the file; if it was reduced to this only, then the
total time would go from 5.5 min to less than 1.5 min, which is what I see from 'ES File Explorer' copying a file.

The next one I see that is quite odd is:

- 5734 ms in Dfs.resolve() called from SmbFile.send(), called 168 times in 29 seconds.

It's no nig deal, but it does account for 78% of the time in SmbFile.send(), and does seem to actually ask the OS for name
translation on each call (there are 168 calls to InetAddress.getAllByNameImpl()).

Which leads to my second question:

*Q2:  Is there any optimization that I can perform to reduce the DfsResolve() calls or cost?*


I may of course be barking up the wrong tree here, this may be a simple unavoidable result of using SMB, but the initial stats (file
copy time using a different app) leads me to believe otherwise.

Any help would be greatly appreciated!

Thanks.




 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/jcifs/attachments/20130225/086f53f2/attachment.html>