On Thu, 2 May 2013 04:49:27 +0100 Michael Blumenkrantz <michael.blumenkra...@gmail.com> said:
> On Thu, May 2, 2013 at 1:04 AM, Carsten Haitzler <ras...@rasterman.com>wrote: > > > 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. > > > > If you're using JSON for RPC, it doesn't make sense. This is a very common > use case. but that is not the point of the json parser jackdaniels etc. are talking about. it is meant to load and store large blobs of structured data... not much unlike edc files... so you need to have the view of "general usage where it may easily be pushed to load large blobs of json of a few mb a pop..." > > > 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. > > Oh noes, scary __UNDERSCORE files and lack of build system which are > irrelevant when importing the source! it's more a matter of saying "we dont have to maintain a json parser then if we just use an external one"... if u import it.. then u are going to be maintaining it. if you don't then the above pretty much means its not available as a package to link to AND has a low chance of acceptance asking people to go download the zip file and figure out how to compile a .so themselves by hand. i covered the case of importing as the other option below. > > 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. > > That's the entire idea behind having a sub-1000 line parser, which is one > of the cornerstones of Cedric's stance that we should write our won. it then means we end up forking it and having to maintain 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. > > Cedric's coding conventions are pretty far from it too, but we still let > him work on Edje. read cjson. not only is it pretty far... its in a whole other galaxy... seriously. entire functions in 1 line of code with almost zero whitespace.... we'll end up reformatting these just to read it... and once we reformat.. we fork. and when we fork.. we now maintain fully. like all forks it becomes totally our cost/responsibility. > > 3. it will duplicate all things via "strdups" so we can't hope to minimize > > string copies in memory. > > > > Not a great argument since we could easily just s/strdup/stringshare/. as above. becomes a fork. when we then make it use eina hash too and more internally we basically now maintain a json parser anyway.. it just STARTED life as "copy someone elses" but after that it's out job entirely. > > 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). > > This is a valid point, and really the only one you've made. cJSON is NOT > great for a general use case. It fits the needs of RPC perfectly, but > that's about it. you should see this point in the context of the others too. there is a need for a GENERAL PURPOSE parser. and that means exposing as structures that are easy to deal with... and are efficient. > > 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 > > > > -- ------------- 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
