<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
For brevity, the summary is I have two questions regarding saving a
file to a windows (Samba) share:<br>
<b><br>
Q1: C</b><b>an I reduce the number of times it calls peekKey()?</b><br>
<b>Q2: Is there any optimization that I can perform to reduce the
DfsResolve() calls or cost?</b><br>
<br>
<br>
The background for these questions is below...<br>
<br>
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).<br>
<br>
For some numbers:<br>
<br>
- save locally (sdcard) approx 1 minute (80mb file)<br>
- save to network approx 5min 30sec (80mb file)<br>
- copy file from local to network (using ES File Explorer), approx 1
min 30 (80mb file)<br>
<br>
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:<br>
<br>
- 28,972ms total time<br>
- 4007 ms total CPU (so it's spending 85% of its time waiting)<br>
- of the total time, 53.7% (15571ms) is spent in
SmbTransport.peekKey(). It was called a total of 337 times in the 29
seconds.<br>
<br>
I assume that the peekKey() time is waiting for an ACK of some kind.<br>
<br>
So the first question is: <br>
<br>
<b>Q1: C</b><b>an I reduce the number of times it calls peekKey()?</b><br>
<br>
Once I ignore the peekKey() related calls (Transport.readn(),
PlainSocketInputStream.read() etc), the next biggest time is:<br>
<br>
- 7371ms in SmbFileOutputStream.writeDirect()<br>
<br>
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.<br>
<br>
The next one I see that is quite odd is:<br>
<br>
- 5734 ms in Dfs.resolve() called from SmbFile.send(), called 168
times in 29 seconds.<br>
<br>
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()).<br>
<br>
Which leads to my second question:<br>
<br>
<b>Q2: Is there any optimization that I can perform to reduce the
DfsResolve() calls or cost?</b><br>
<br>
<br>
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.<br>
<br>
Any help would be greatly appreciated!<br>
<br>
Thanks.<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>