https://issues.apache.org/bugzilla/show_bug.cgi?id=56953
Bug ID: 56953
Summary: A improvement for "DataInputStream"
Product: Tomcat 7
Version: trunk
Hardware: PC
Status: NEW
Severity: enhancement
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: hzha...@ebay.com
Created attachment 31993
--> https://issues.apache.org/bugzilla/attachment.cgi?id=31993&action=edit
patch
The method "readUnsignedShort()" of "DataInputStream" read the stream twice to
get the unsigned short. This happens even if the "BufferedInputStream" is
invoked.
public final int readUnsignedShort() throws IOException {
int ch1 = in.read();
int ch2 = in.read();
if ((ch1 | ch2) < 0)
throw new EOFException();
return (ch1 << 8) + (ch2 << 0);
}
It may cause extra cost for some boundary processing. This case also appears in
"readInt", "readChar", etc. It is obvious in some large projects.
Use a interface to replace "DataInputStream" by "FastDataInputStream" can
bypass these processes. The "FastDataInputStream" gets the bytes from buffer
directly.
//========== method in FastDataInputStream. ==========
public int readUnsignedShort() throws IOException{
if(pos + 1 >= cnt) {
fill();
if(pos + 1 >= cnt) throw new EOFException();
}
int ch1 = this.buf[pos++] & 0xff;
int ch2 = this.buf[pos++] & 0xff;
return (ch1 << 8) + (ch2 << 0);
}
Benefit shows bellow, it is got from the test case in attachment.
=====lots of jar files=====
DataInputStream: 592
FastDataInputStream: 488
=====few jar files=====
DataInputStream: 93
FastDataInputStream: 77
notice: The optimized method is called before original method in the test case,
so the real result should be more obvious.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
