Thiago, It looks like a win on all sides from a design perspective. Where are we on diagnostics? Meaning, have you been able to find a WireShark parser? Have you added a printCBOR(...) method to dump the contents to a log?
These are phase III items to help test engineering, etc. Pat > -----Original Message----- > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira > Sent: Friday, May 22, 2015 6:14 PM > To: iotivity-dev at lists.iotivity.org > Subject: [dev] The move to CBOR > > Hello > > I've just pushed a series of commits that contain my latest updates on the > move to CBOR. The commits (see list at the bottom of this email) implement > the > following: > * modify several functions and structures dealing with payloads to keep the > payload size in an extra variable, instead of using strlen > * import the "libcbor" library [1] > * add two cbor source files to the build > * convert several payloads in the base resources from JSON to CBOR [2] > > Missing: > * there are still a couple more places where JSON is used and I haven't fixed > * a Cereal sink for the C++ API > * modifying the CoAP Content Format PDU header from 50 > (application/json) to > 60 (application/cbor) -- I'd have done this, but I couldn't find where > it's > done, as COAP_MEDIATYPE_APPLICATION_JSON isn't used anywhere in > our code > * any code above the C++ layer that assumes that the payload is JSON, > instead > of using OCRepresentation like it should > > Other improvements: > * the CBOR encoder does not allocate memory, unlike the cJSON one. This > should shrink dynamic memory usage on all devices and open up the > for the possibility of zero copy > * this gets rid of manual JSON encoders and decoders. I found one in the > source that is not even compliant > > I was asked for some benchmarks. First off, code sizes: > $ find cjson libcbor -name \*.o | xargs size > text data bss dec hex filename > 7787 16 8 7811 1e83 cjson/cJSON.o > 1077 0 0 1077 435 libcbor/src/cborencoder.o > 2870 0 0 2870 b36 libcbor/src/cborparser.o > > Second, I prepared some performance benchmarks: > JSON CBOR Improvement > CPU ticks 14025 5100 2,75 > CPU cycles 17127 6167 2,78 > Branch misses 34,04 0,02 2057 > Instructions 34555 5980 5,78 > L1 data cache loads 10436 2017 5,17 > L1 data cache misses 13,90 0,11 127 > [see attached image for a graph] > > Notes: > [1] the library will exist in an upstream on GitHub. I am in the process of > obtaining the necessary repository from the Intel GitHub account, so this > doesn't live on my personal GitHub account > > [2] the conversion is unconditional. I am not keeping the old JSON code. > > Relevant commits: > https://gerrit.iotivity.org/gerrit/969 > https://gerrit.iotivity.org/gerrit/968 > https://gerrit.iotivity.org/gerrit/975 > https://gerrit.iotivity.org/gerrit/991 > https://gerrit.iotivity.org/gerrit/905 > https://gerrit.iotivity.org/gerrit/992 > https://gerrit.iotivity.org/gerrit/967 > https://gerrit.iotivity.org/gerrit/1102 > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center
