3 ms·
While we're planning on open sourcing some things, I'm not sure we'll ever open source that one. Even though it was much faster, it didn't see much time in prod
by jtolds 12y ago
While we're planning on open sourcing some things, I'm not sure we'll ever open source that one. Even though it was much faster, it didn't see much time in production due to the less than desirable impact it made (go Amdahl's law), and it still has some bugs and was highly customized to our specific protocol buffer definitions.
Internally, Google has something faster for Python, but they haven't released it yet. You might try putting pressure on them here: https://code.google.com/p/protobuf/issues/detail?id=434 https://code.google.com/p/protobuf/issues/detail?id=434
http://yz.mit.edu/wp/fast-native-c-protocol-buffers-from-python/ http://yz.mit.edu/wp/fast-native-c-protocol-buffers-from-pyt... talks about the issues some more with some links to other rewrite attempts.
- sandGorgon 12y agowould you have gone with thrift if you had to do it all over again ? I ask because I saw the bug description and the glacial response ;)
- jtolds 12y agoNo, I think we're honestly even more sold on protocol buffers' wire format than before. That said, if I did want to go looking elsewhere, I think the main serialization format I am really interested in is Cap'n Proto: http://kentonv.github.io/capnproto/ http://kentonv.github.io/capnproto/