代码之家 › 专栏 › 技术社区 › Riley Lark

GWT是否高效地序列化java.lang.long?

network-efficiency performance gwt serialization

4

Riley Lark · 技术社区 · 15 年前

我正在通过GWT RPC机制从客户机向服务器来回发送对象ID。ID以长整型(8字节)的形式从数据存储中输出。我想我所有的ID只需要4个字节,但有些是随机的能够会给我一个5字节(或其他)的值。

GWT是否会明智地将这些值打包成一些可变长度的编码,从而平均节省空间?我可以指定在某个地方这样做吗?或者,我应该编写自己的代码来将long复制到ints并注意那些异常情况吗?

谢谢~

2 回复 | 直到 15 年前

1

4

Arthur Maltson 15 年前

如中所述 GWT documentation .

长的 :javascript没有64位整型,因此需要特别考虑。在GWT1.5之前,long类型被简单地映射到64位javascript浮点值的整数范围,使long变量的实际范围小于完整的64位。从GWT1.5开始,长原语被模拟为一对32位整数,并在整个64位范围内可靠工作。模拟溢出以匹配预期的行为。有几个注意事项。由于底层仿真,长时间操作的大量使用将对性能产生影响。此外,长原语不能在JSNI代码中使用,因为它们不是本机JavaScript数字类型。

如果您的ID可以容纳一个整数,那么您可以更好地使用它。否则,如果您使用的是DTO,请将ID设置为double,它实际上存在于javascript中。

2

4

Igor Klimer 15 年前

GWT对有效负载为256字节或更大的响应使用gzip压缩。如果您的响应中有很多零字节,那么这应该很好地工作。

从 RemoteServiceServlet.shouldCompressResponse :

确定是否对给定的servlet请求应该或应该不是gzip压缩。这种方法是仅在以下情况下调用请求者接受gzip编码。

此实现当前返回如果响应字符串是估计的字节长度大于 256字节。子类可以重写这个逻辑。

因此,服务器首先检查请求者(通常是浏览器)是否接受gzip编码。在内部, java.util.zip.GZIPOutputStream 已使用-请参见 RPCServerUtils . 在客户端,浏览器的工作是 decompress the gzipped payload -因为这是在本机代码中完成的,所以应该相当快。