使用protobuff构建器作为通用数据对象的性能分析

由于protobuffer是Java序列化的绝妙选择，因此我们广泛使用它。另外，我们使用java构建器作为通用数据对象。在研究使用消息构建器构建对象，形成实例参数以及构成对象的普通Java基元的速度时，我们发现对于包含6个基元字段的对象，使用构建器（它是对象的参数）构造对象，花了1.1ms，而使用java原语只花了0.3ms！并列出50个这样的领域！建设者是沉重的，使用它们作为一般数据对象在这个程度上影响建设的速度？使用protobuff构建器作为通用数据对象的性能分析

下面是样本设计我用于分析，

message PersonList 
{ 
    repeated Person = 1; 

    message Person 
    { 
     optional string name = 1; 
     optional int32 age = 2; 
     optional string place = 3; 
     optional bool alive = 4; 
     optional string profession = 5; 
    } 
}  

The java equivalent 

Class PersonList { 

    List<Person> personList; 

    Class Person { 
     String name; 
     int age; 
     String place; 
     boolean alive; 
     String profession; 
    } 
    /* getters and setters*/ 
}

来源

2014-02-05 Aarish Ramesh

我也很难想象任何一个只包含“6个原始值”可能需要7毫秒构建。这应该是10万倍。所以我不确定我明白你在做什么。

也就是说，protobuf建设者确实比一个典型的POJO更复杂的原因有很多。例如，protobuf对象会跟踪当前设置的字段。此外，重复的基元被装箱，与Java基元数组相比，这使得它们效率很低。所以如果你单独测量施工时间，你可能会看到明显的差异。但是，与其他应用程序代码所花费的时间相比，这些效果通常无关紧要。

来源

2014-02-06 07:32:44

对不起，这些结果是错误的..我重新做了anaysis，发现时间分别为1.1ms和0.3ms，分别使用builder和普通的java对象。在这种情况下的时间差异不是什么大不了的。但是，向列表中添加元素时，结果令人震惊。要添加100个元素，使用上面的构建器设计（构建器设计包括通过protoListbuilder的java包装器）需要约6ms，而java对象的设置需要0.4 ms。 –

雅我同意你的观点，认为这些与应用程序代码花费的时间相比并不相关，但是当涉及到更大规模时，这并不重要！ –

将100个元素添加到列表中应该需要几微秒，而不是几毫秒，所以我觉得您的代码中必须有其他内容。但是，是的，POJO可能会比内存数据结构更好地执行protobuf构建器。仅当需要序列化时才使用protobufs - protobuf序列化比Java序列化快得多。 –

使用protobuff构建器作为通用数据对象的性能分析

回答

相关问题