Ok, now we're talkin'. :) The "faster" statement is indeed ambiguous and could mean one in three things;
1. It is fast to ship over the wire 2. It is fast to marshall 3. It is fast to work with, as a human I am referring to number 3, because in command-land, messages are neither marshalled or transferred often enough to make any significant difference in terms of performance. Let's say around command is being requested once every second, on average, by multiple clients on a daily basis, and that, for the sake of familiarity, the commands are similar to "render me this" or "render me that" For 1 and 2 to be relevant, messages would probably have to be sent by the thousands or even millions; which is of course often the case, but possible not in the context of the Command Pattern. So, in terms of human performance, I stand by my statement that working with a structured message is slower, yet less prone to (again, human) error. Thoughts? On Tuesday, May 20, 2014, Justin Israel <[email protected]> wrote: > I think you have made a completely inaccurate statement here. Or at least > one that is ambiguous. You referred to a structured message as slower, and > an unstructured message as faster because "it requires no parsing". > > When you send the json message across the wire, it will be a single > message that will be read entirely and then it has to go through the json > load process to be parsed and turned into an object on the other end. It > also can only represent a few types in its standard spec. > > Protobuf has a binary format which can be smaller in size and faster to > read because as it reads each index it can lookup the type from the proto > and know what to read for the value. > > Have you done tests that suggest this fast/slow categorization is valid? > Depending on your message size it could either be true, false, or > negligible > https://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking > > In that test, protobuf ended up being smaller and faster overall and was > only slowest in the object creation component of the test. > > I'm just mentioning this because it immediately struck me as strange that > you would represent the options by this criteria (fast/error prone, > slow/less error prone). It usually depends on your message structure and > size and required profiling. > On May 21, 2014 3:59 AM, "Marcus Ottosson" > <[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>> > wrote: > >> >> - >> >> Unstructured is fast, more prone to error >> - >> >> Structured is slow, less prone to error >> >> I should say, “..prone to *human* error”. The computer doesn’t care >> either way. >> >> >> >> On 20 May 2014 16:57, Marcus Ottosson <[email protected]> wrote: >> >> Yes you are probably right. >> >> This topic is about JSON versus Protobuf for transmitting commands across >> processes; let’s refer to these as *unstructured* versus >> *structured*respectively. To be explicit, and for those not familiar with >> protobuf or >> schemas and what not, here’s what we’re comparing: >> >> - >> >> Unstructured is fast, more prone to error >> - >> >> Structured is slow, less prone to error >> >> Example >> >> *unstructured - client* >> >> >>> message = { >> 'command': 'create', >> 'args': ['age', '5'], >> 'id': 'uuid' # Unique id for client >> }>>> packed_message = json.dumps(message)>>> socket.send(packed_message)>>> >> return_value = socket.recv()# Blocks until server responds>>> # No >> post-processing required >> >> *unstructured - server* >> >> >>> packed_message = socket.recv()>>> message = >> >>> json.loads(packed_message)>>> command = message['command'] >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBr0gSNLeDMk2uVZfK-s_c_g5w%3D88%3DU9u3BzmoA%3DNaLmw%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBr0gSNLeDMk2uVZfK-s_c_g5w%3D88%3DU9u3BzmoA%3DNaLmw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > [email protected]<javascript:_e(%7B%7D,'cvml','python_inside_maya%[email protected]');> > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0pHAAgzw2zjN%2Bj0MQgsdMYh-cRL4rRQttWYLAu21OTWw%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0pHAAgzw2zjN%2Bj0MQgsdMYh-cRL4rRQttWYLAu21OTWw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- *Marcus Ottosson* [email protected] -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAMGtKXS6%3DJvKxJChsTSkBce1O6VkB5E_3eiYrtCm590Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
