I have been measuring the time it takes to complete one
entire Action.postControlAction(), so essentialy
completing an action request. I noticed this takes much
longer with CyberLink than for example with the intel
UPnP toolkit.
I could trace the cause to the HTTPPacket.set method,
it creates an array (readBuf) of length
HTTP.getChunkSize(). The chunk size however defaults to
512*1024 bytes. So for every HTTPPacket which is
received an array of half a megabyte is created. By
setting the chunk size to a few kilobytes I could
reduce the time it takes to complete an entire action
request with a factor 10.
I don't no if there is a good reason for setting the
chunk size this big, however if there is not it might
be advisable to reduce the default chunk size
signifcantly (of course a fix in my case is setting the
cunk size with HTTP.setChunkSize(), but if you don't
know this things can get pretty slow) .
protected boolean set(InputStream in, boolean onlyHeaders)
{
<snip>
long conLen = getContentLength();
if (0 < conLen) {
int chunkSize = HTTP.getChunkSize();
<ALLOCATE ARRAY OF 1024*512 bytes!!>
char readBuf[] = new char[chunkSize];
long readCnt = 0;
}
Logged In: YES
user_id=1244126
Thanks!! this makes it a lot faster, but still slow compared to
the Intel CLR SDK. Is this because of Java, or is it possible to
optimize this futher?
Logged In: YES
user_id=1262118
I don't think there can be made much improvement anywhere
else. Though I must say the performance after this change
gets pretty close to the Intel UPnP toolkits performance (at
least with the few tests I did with the intel services).
The things "slowing" the API down are the xmlParser, when
receiving a SOAP response, and also the time it takes Java
to create a socket and connect it to some remote host & port.
Logged In: YES
user_id=1262118
You could use the kXML parser instead of Xerces. In my
experience kXML is faster.
Logged In: YES
user_id=901512
Originator: NO
what kind of slow down have you noticed?