Protobuf Performance Comparison and Points to Consider When Deciding If It’s Right For You
What is Protobuf?Developed by Google for object serialization, its an open source library, and available for multiple languages. It’s a fast buffer which does the object serialization, you can consider it the same as XML but faster, smaller, and finally both serialization and de-serialization are faster than any other available approach.What is the procedure?One needs to define the object structure, it can be done by defining the .proto file, which defines required and optional fields of the object.Once the proto file is generated, one needs to use supplied code generator, this utility is language specific and generates language specific code. If it’s used for Java then you can consider that this utility generates the Java pojo for serialization and de-serialization.Now using the supplied library, generated beans/models and .proto files, one can serialize or de- serialize the response.Why should I use it?JSON and XML transmit data with metadata details, and which adds load on payload, requires more memory compared to Protobuf. Protobuf compresses the data and generates dense data. If compared to XML Fast buffers it takes almost a 1/3rd of the size and if compared to JSON then its ½.JSON and XML are more readable and not secure to transmit data over the network. If you want your response not to be readable by user then you can use Protobuf.The consumer of the service needs the .proto file to de-serialize the object stream.Less CPU and Memory will be consumed for serialization and de- serialization, so processing time on mobile devices is faster compared to JSON.ComparisonHere I considered a web application which sends data using REST service, and a web page which renders the data on screen. I have used the total time to render a page using JSON and Proto, end-to-end to make sure I am covering, serialization, data transmission, de- serialization and DOM rendering. I compared it with different network speed, broadband, 3G and 2G. NetworkJSONProtoTimeBroadband555 MS359 MSPayload sizeBroadband1.2 MB684KBTime3G (1Mb/S)7.93 S4.6 SPayload size3G (1Mb/S)1.2 MB684KBTime (ms)2G22 S13.73 SPayload size2G1.2 MB684KBNetworkJSONProtoTimeBroadband288 MS293 MSPayload sizeBroadband512 KB292 KBTime3G (1Mb/S)2.91 S1.86 SPayload size3G (1Mb/S)512 KB292 KBTime2G9.80 S6.06 SPayload size2G512 KB292 KBNetworkJSONProtoTimeBroadband229 MS233 MSPayload sizeBroadband302 KB269 BTime3G (1Mb/S)318 MS331 MSPayload size3G (1Mb/S)302 KB269 BTime2G723 MS808 MSPayload size2G302 KB269 BPoints to considerIf the payload is larger than 300KB then one can gain more speed from the performance perspective.If application needs to send smaller chunks of data (an IoT use case) then think about if the system really needs the status real time or if we can merge the events triggered and upload the payload after an interval. You'll need to ask the question, which one is more applicable? Sending 40KB payloads 10 times or sending a 400KB once?Does the application need object serialization, which is platform independent, not human readable, and takes lesser memory? If yes the go with Protobuf.I haven’t tested the serialization and de-serialization performance on smaller devices like mobile or for IoT. Definitely that will be one more aspect to consider.It’s not limited only for REST services which returns the data in JSON or XML to compare with, one can use Protobuf for MQ, RFC.Protobuf makes more sense if you have same web application or rest services to be used by desktop and mobile devices.I used Spring Boot for REST service, bytebuffer.js on JS side and Google Protocol buffer libraries.