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. > > > 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! > > 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. > 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. > 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/. > 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. > 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
