On Wed, 1 May 2013 14:56:32 +0100 Michael Blumenkrantz <michael.blumenkra...@gmail.com> said:
> cJSON, at least, exposes no hashes, lists, or any of that; I don't know > what crazy parsers you kids have been using which do this, but they > shouldn't since JSON doesn't have any concept of such things. errr.. json is really a tree of string key -> values (where value can be a subtree) so thus by nature its a list and/or hash of strings and/or subtrees make sense. > This is all the code I have which uses an external JSON parser at present. > It serializes and deserializes JSON-RPC (based on latest draft spec) very > pedantically to/from Eina_Value, and all strings get stringshared. > > http://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/lib/azy/azy_content_json.c ok. so still about 500 loc to drive cjson and convert back to data structs (eina-value in this case). and... behind "getobjectitem" in cjson is probably a hash... and probably a set of lists... etc. duplicating strings inside of cjson that then are extracted and stuffed into stringshare strings. :) and we ned up with another fun thing... to use cjson... at least ubuntu users can't just apt-get install it. no package. so we have to copy it into the efl tree or make packages or force pl to download and compile it just for a small lib dep... and it nicely comes with a zip file with no makefile or configure... or any build infra, with __MACOSX metadata hidden files all thru the zip... good luck with that. so import the src entirely is the only way... and then... take a read of the src. seriously. once we import it we will have to fix it and maintain it entirely... THIS is just one of many functions where the WHOLE function including definition is on a single line: void cJSON_ReplaceItemInObject(cJSON *object,const char *string,cJSON *newitem){int i=0;cJSON *c=object->child;while(c && cJSON_strcasecmp (c->string,string))i++,c=c->next;if(c){newitem->string=cJSON_strdup (string);cJSON_ReplaceItemInArray(object,i,newitem);}} no newlines. there's a whole batch of these 11-liner funcs there, it's not a one-off oh an i was wrong. it has no lists or hashes. it just has arrays of string->value and cJSON_GetObjectItem is... a linear O(n) walk thru the array strcmping every item until key found, then return... so for objects with lots of keys... we're talking a lot of walking... might be doable for like things with < 10 keys... not so for a more expansive and generic need. so a quick 5 minute evaluation of cjson tells me: 1. we can't just link to it... and HAVE to import it. 2. it's coding conventions are far from what we are used to and do in efl land, so we'll have a nice "sore thumb" inside our src tree. 3. it will duplicate all things via "strdups" so we can't hope to minimize string copies in memory. 4. walking cjson stuff is either looking up every key you want with O(n) per lookup with strcmps ... OR... walking the array by index and converting to a hash then doing hash lookups (back to #3). 5. conclusion... cjson would not be the best choice of json parser to roll into our src tree... :) > On Wed, May 1, 2013 at 2:46 PM, Tom Hacohen <tom.haco...@samsung.com> wrote: > > > On 01/05/13 14:15, Cedric BAIL wrote: > > > WTF ! I am not saying that without a benchmark ! Where do you think > > > that came from ? Just random praising for the fun ? > > > > You said you haven't tested cJSON, only json-c. I asked you about it!> > > > Because there is no complexity there. It just work. There is no > > > maintenance cost. There is no need to bring an external dependency for > > > 100 lines of code. > > > > Pfft yeah, sounds like every other piece of code every written. > > > > > > > >> Mike can interject, as he has used cJSON before, and I don't remember > > him > > >> mentioning any issues. > > > > > > So running cJSON, then converting to Eina_Value or C structure by hand > > > in the application side is faster than just running a stupid automate > > > that produce them in the first place... > > > > Let's wait for mike. I wonder what he did. Also I wonder if you'd end up > > changing the Eina_Value and lists to your own struct anyway 99.99% of > > the time. Surely there must be a lib that let's you parse it straight to > > your data type, but that might be slower. > > > > > > > >> Your main argument is the speed, though I have requested benchmarks and > > >> comparisons with eina_json yet I have seen none. If it's so simple to > > >> implement, how come there are so many implementations? How come they > > vary in > > >> speed so much? And where do we stand compared to others? > > > > > > Because it is damn easy to write one implementation ! Because most of > > > the speed doesn't come from the parser automate who is always the same > > > stupid table, but from the hash, object, list and array object > > > manipulated. That is where the cost come from. And I am not only > > > arguing about speed, but also integration and simplicity of use. > > > Really forcing everyone to link with another library for less than > > > 1000 lines of code, to have another object api to manipulate, to do > > > all the conversion manually is a great help to every one. Of course it > > > is doable in the application. Of course you can write your own, it is > > > so damn easy. > > > > > > As for the benchmark, we are going to reuse the one written by QT. I > > > am going to do proper review and cleaning as necessary after 1.9, > > > there is nothing to look at at this stage. I have already spend more > > > time arguing on that subject that I am sure it will take me to write > > > an implementation from scratch and likely to ever maintain it. > > > > Let's wait for the benchmarks then. I find it really odd that the only > > different in speed is the implementations of the hash-tables and lists. > > > > -- > > Tom. > > > > > > > > ------------------------------------------------------------------------------ > > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > > Get 100% visibility into your production application - at no cost. > > Code-level diagnostics for performance bottlenecks with <2% overhead > > Download for free and get started troubleshooting in minutes. > > http://p.sf.net/sfu/appdyn_d2d_ap1 > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
