Scott Ferguson wrote:
>
> On Jun 22, 2006, at 5:04 PM, Tom Kaitchuck wrote:
>
>> Hello all,
>> I have been working on adapting hessian for a project I am working on. I
>> have already created a modified version of com.caucho.hessian.io which
>> has performance enhancements, code cleanup, feature removal, and a
>> number of unit tests. I plan to continue to make improvements, but have
>> no intention of providing any support. If anyone would find this useful,
>> just let me know where to send the diff.
>
> Interesting. What performance enhancements did you find?
The major ones are:
In hessianInput there are sever sections of code that look like this:
_chunkLength = (read() << 8) + read();
ByteArrayOutputStream bos = new ByteArrayOutputStream();
int data;
while ((data = parseByte()) >= 0)
bos.write(data);
return bos.toByteArray();
However it is better to do:
_chunkLength = (read () << 8) + read ();
byte[] result = new byte[_chunkLength];
_is.read(result);
return result;
And in MapSerializer there is a section that looks like:
Iterator iter = map.keySet().iterator();
while (iter.hasNext()) {
Object key = iter.next();
out.writeObject(key);
Object value = map.get(key);
out.writeObject(value);
}
But is better to do:
Iterator < Map.Entry > iter = map.entrySet ().iterator ();
while (iter.hasNext ()) {
Map.Entry entry = iter.next ();
out.writeObject (entry.getKey ());
out.writeObject (entry.getValue ());
}
>> I noticed that you have added some new types in the draft for Hessian
>> 2.0, but it is not clear from the WIKI what each of these values
>> actually represents.
>
> I added a new page at http://wiki.caucho.com/Hessian_2.0 to describe
> some of the draft ideas.
>
>> I would also like to specifically request that if
>> the comment period is not closed c/c++ primitives be supported, as I
>> will need to implement this anyway, and I would prefer not to break
>> compatibility.
>
> We just started brainstorming for Hessian 2.0. I'm guessing it will
> be at least 6 months before we make it final. No sense rushing in it.
>
> The goal is not to add any new types, merely compact representations.
>
> c/c++ primitives should already be supported, just in a somewhat
> wasteful manner, since you can encode a byte using I x x x x.
I was thinking more along the lines of supporting both *signed and
unsigned *versions of:
byte, short, int, long, long long, float, double and quad. The point of
signed vs unsigned is not that you could not encode the same data some
other way, but that a client should be able to query whether something
was sent as a signed or unsigned integer. Of course if the client calls
a hypothetical function getSignedInt(), they should get it is a signed
integer, regardless of what type it is in the datagram.
Received on Tue 27 Jun 2006 10:28:07 -0700
This archive was generated by hypermail 2.1.8 : Thu Sep 28 2006 - 20:16:41 PDT