6 ms·

But you can install a c extension implementation for ruby (or pretty much any other language that doesn't already have native JSON built in) on your server fixi

by falien 14y ago

But you can install a c extension implementation for ruby (or pretty much any other language that doesn't already have native JSON built in) on your server fixing that performance gap. That's exactly what you can't do on the browser JS side for MsgPack.

olsn 14y ago
then you could get a c extension for MsgPack, that would have to parse less bytes than the JSON c extension and therefore be faster JSON is very good, no doubt about that - but i think that even JSON can be optimized, does not have to be by MsgPack, but probably by a binary format.
- falien 14y ago
  My point was that you can't install a c extension in a browser. I assumed that all the MsgPack libraries would be C or equivalent performance-wise. As to text vs binary, I'll just leave this link here: http://catb.org/~esr/writings/taoup/html/textualitychapter.html http://catb.org/~esr/writings/taoup/html/textualitychapter.h...
- olsn 14y ago
  i understood your point, however the speed in the user's browser is not important since it's just 1 operation, whereas the server has to do most of the operations decoding/encoding all that i guess there are pros and cons on both sides, certainly nice would be something like a native BSON implementation with extensions in the browser/debugger to make it readable
  - batista 14y ago
    >i understood your point, however the speed in the user's browser is not important since it's just 1 operation, whereas the server has to do most of the operations decoding/encoding all that Speed in the user's browser is VERY important.
    - olsn 14y ago
      it is, but can you tell the difference between 0.5ms or 1ms? ;)
      - cheald 14y ago
        When you're doing it 100 times? Sure.
  - falien 14y ago
    Your blog post suggests using MsgPack as a drop in replacement for JSON for client-server communications. In that context every encode/decode operation on the server would be matched by one in the client browser. The <5% gain in performance on the server (and I think that is generous) cannot possibly make up for the performance hit of a javascript implementation of MsgPack. When MsgPack was written a lot of JSON in the browser was still not native so an argument could be made if you desperately needed that bandwidth and it worked better than average for your specific workload. That is simply not true anymore.
    - olsn 14y ago
      i'm using it in Flash, so there is absolutely no JavaScript involved in my case...

by falien 14y ago

olsn 14y ago

then you could get a c extension for MsgPack, that would have to parse less bytes than the JSON c extension and therefore be faster JSON is very good, no doubt about that - but i think that even JSON can be optimized, does not have to be by MsgPack, but probably by a binary format.

falien 14y ago
My point was that you can't install a c extension in a browser. I assumed that all the MsgPack libraries would be C or equivalent performance-wise. As to text vs binary, I'll just leave this link here: http://catb.org/~esr/writings/taoup/html/textualitychapter.html http://catb.org/~esr/writings/taoup/html/textualitychapter.h...
olsn 14y ago
i understood your point, however the speed in the user's browser is not important since it's just 1 operation, whereas the server has to do most of the operations decoding/encoding all that i guess there are pros and cons on both sides, certainly nice would be something like a native BSON implementation with extensions in the browser/debugger to make it readable
- batista 14y ago
  >i understood your point, however the speed in the user's browser is not important since it's just 1 operation, whereas the server has to do most of the operations decoding/encoding all that Speed in the user's browser is VERY important.
  - olsn 14y ago
    it is, but can you tell the difference between 0.5ms or 1ms? ;)
    - cheald 14y ago
      When you're doing it 100 times? Sure.
- falien 14y ago
  Your blog post suggests using MsgPack as a drop in replacement for JSON for client-server communications. In that context every encode/decode operation on the server would be matched by one in the client browser. The <5% gain in performance on the server (and I think that is generous) cannot possibly make up for the performance hit of a javascript implementation of MsgPack. When MsgPack was written a lot of JSON in the browser was still not native so an argument could be made if you desperately needed that bandwidth and it worked better than average for your specific workload. That is simply not true anymore.
  - olsn 14y ago
    i'm using it in Flash, so there is absolutely no JavaScript involved in my case...