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