ram*_*lla 2 performance gwt rpc json
我们正在使用带有RPC服务返回列表的IE8恶梦,其中包含(或多或少)60个对象,每个对象有5个属性.虽然现代浏览器可以完成这项工作,但IE8的响应能力还不够.关于这一点甚至存在一个公开的问题.
我们计划为需要发送大型对象列表的服务更改RPC,但我们希望更改服务器和客户端上可能的最小代码量.
第一个问题:对于这种情况,JSON反序列化在IE8上会运行得更快吗?
我们喜欢简单的RPC服务.我们有CustomRemoteService实现,CustomAsyncCallback实现,CustomRPCException实现等等.射频对我们来说是一个很大的变化.
第二个问题:使用返回单个JSON字符串然后反序列化客户端的RPC服务可以完成这项工作吗?
或者你能推荐另一种方法吗?
谢谢!
第一个问题:对于这种情况,JSON反序列化在IE8上会运行得更快吗?
它应该运行得更快,因为IE8支持本机JSON解析(在IE6和7中,您可以使用eval()仍然比手动解析字符串更快的运行速度)
但它高度取决于您对解析对象的处理方式:如果您处理它从它重建POJO,你可能会失去所有JSON的好处; 另一方面,JS覆盖的开销为零,但需要将所有数组或列表更改为JsArrays,并且日期不能轻易地用JSON编码,它们需要额外的编组/解组.
第二个问题:使用返回单个JSON字符串然后反序列化客户端的RPC服务可以完成这项工作吗?
如果你的JSON处理比RPC反序列化重量轻,那么是的.在客户端解析响应很简单eval()(是的,奇怪的是它在可用时不使用本机JSON),然后在解析的对象中查找; RPC反序列化中最大的成本是解释值以重建对象; 获取字符串只是数组中的查找,因此它取决于您稍后对该字符串执行的操作.
| 归档时间: |
|
| 查看次数: |
1093 次 |
| 最近记录: |