Test the influence of Protobuffer Definition Format on its time and space.
The following measure the number of bytes that the Protobuffer A command converts to std: string:
A) AddLayer: 108
B) AddSource: 209
C) MoveLayer: 44
D) DeleteLayer: 48
However, the actual application uses the B command to receive and convert it to the C command. The C command is then split into the command, and the whole command receives A large number of bytes. The data is as follows:
A) AddLayer + AddSource: 410
B) MoveLayer: 150
C) DeleteLayer: 153
From the comparison between the two, we can conclude that the two nesting commands bring about nearly 100 bytes of overhead. Obviously, the fewer layers of nesting, the smaller the number of bytes to be converted to the string. In addition, the search data shows that Protobuffer has a high time overhead when it contains the repeated element, because the memory is re-allocated when the number of repeated elements reaches a certain value. Therefore, from the perspective of time and space, there are two suggestions for Protobuffer definition. One is to use as few nesting as possible to reduce the space overhead (personal understanding, protobuffer definition should be flat); second, repeated elements should not be too many to reduce time overhead.
References:
Http://blog.csdn.net/yang3wei/article/details/46360099