On Fri, Oct 7, 2011 at 4:30 PM, Jedrzej Nowacki <[email protected]>wrote:
> ** > > On Wednesday 5. October 2011 15.51.23 you wrote: > > > Hi Jedrzej, > > > > > > On Tue, Oct 4, 2011 at 12:50 PM, Jedrzej Nowacki > > > > > > <[email protected]> wrote: > > > > Hi, > > > > > > > > As Thiago already pointed out, we have few (too many) competing > > > > implementation of JSON parsers, and two different environments (C++ and > > > > JS/QML) in which they should work. We should have only one > implementation > > > > mainly because we can't allow behavior differences and because of > general > > > > maintenance costs (testing, performance improvements, etc.). > > > > > > > > Currently, I do not see obvious winner. For QML, V8 implementation may > be > > > > preferred, as it creates a native JS object, which can be used directly > > > > from a QML application. On other hand from C++ point of view it would > be > > > > an overkill to start full JS environment to parse a tiny json file. But > > > > of course everyone will use QML, so it is not a problem, right :-)? > What > > > > I do not like about qjsonparser mentioned by Girish, is that it uses > > > > QVariant as a type for object storage. It won't be fast, ever. QVariant > > > > is a type safe replacement for void*, and nothing more. I think it is > > > > misuse to treat it as a correct object representation. In Qt, we > already > > > > have two classes, which takes that responsibilities; QObject and > > > > QJSValue. The first should be known to everyone, second represents a JS > > > > object. Another issue related to QVariant is that it always needs to be > > > > converted to something, in a common case you need to iterate over > > > > QVariantMap to create an useful > > > > representation. > > > > > > Right, we are sort of "reusing" QVariant to store the entire json > > > structure since it incidentally happens to support all the types that > > > appear in json :) So, maybe we can make the return value be > > > JsonObject. You can then say: > > > JsonObject map = obj.map("foo"); > > > int someInt = obj.intValue("bar"); > > > JsonArray arr = obj.array("baz"); > > Yes, something like that would be generic and have chance to be fast :-). > On top of it, we may create additional convenience function without much > overhead (like QJSValue or QVariantMap conversion). > > > > > I think we need more benchmarks, before we can make the right decision. > > > > > > I can benchmark my implementation against the others, if the owners > > > can first tell me that it is completely standards compliant (encoding > > > detection etc). I have benchmarked against qjson and it's way faster. > > > The benchmark results are in the qjsonparser repo. > > I tried to benchmark it against v8 json parser. The benchmark is rather a > smoke test, then proper scientific measurement, but it seems that V8 is > significantly faster. Result and test in attachment. Important benchmark > would be to replace v8 json parser by a custom one and see if it doesn't hit > performance of QML. > > > Cheers, > > Jędrek > > > Don't know if this is of much help but V8 has a C++ JSON parser : http://www.google.com/codesearch#W9JxUuHYyMg/trunk/src/json-parser.cc&q=json%20package:http://v8%5C.googlecode%5C.com&type=cs Or that's what i think it is judging by the file name and the things it does..
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
