Thanks for the pointers, Emily and Toby. How can I run a reasonable benchmark? Benchmarking size is easy and I've done that with excellent results, but sanely benchmarking speed? Is there other code in the GWT source with benchmarks that I can look at?
Then there's the issue of massive differences between TraceMonkey/V8/ SquirrelFish Extreme, and the non-jit js engines, but, one step at a time :) On Sep 22, 6:40 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > The next step is to get it into gwt-incubator. I've verified that you have > commit rights there. To stop later name collisions, the package should be > named com.google.gwt.gen2.json. > > We put benchmarks in the test source directory, so, for instance, you might > have: > test\com\google\gwt\gen2\json\client\JsonTest.java and > test\com\google\gwt\gen2\json\client\JsonBenchmark.java > > The test suite, if you have one, should live directly under json, and should > not include the benchmark code. > > You will also need a demo in src-demo/com.google.gwt.gen2.demo.json. Please > feel free to ping me with any questions! > > On Sun, Sep 21, 2008 at 2:14 AM, Reinier Zwitserloot <[EMAIL PROTECTED]>wrote: > > > > > > > Seehttp://code.google.com/p/google-web-toolkit/issues/detail?id=2900 > > > On Sep 21, 8:11 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > > > It was a lot more work than I originally thought, but its done, and it > > > does include the ability to create JSON and not just read it. > > > > I created a little real world scenario type of deal in both the old > > > way and the new way. To my big surprise, the new API is easier to > > > write for AND produces smaller js files! > > > > JS filesize: 13828 in old, vs. 12180 in new. java file size: 2386 > > > characters for old vs. 1688 for new. > > > > I was afraid the compiled size of the new API would be bigger than the > > > old one, but you end up saving 1.5kb! > > > > I don't have committer access, I did sign the CLA. Where do I go from > > > here? > > > > The files I have, other than the boilerplate stuff: > > > - actual source to be included in gwt-user.jar: JSON.java, > > > JSONWriter.java. > > > - extras: JSONTest.java (junit tests) and JSONPerformanceA/ > > > JSONPerformanceB.java (both EntryPoints and used to come up with the > > > above numbers). > > > > The files live in the same package as the existing JSON library > > > (com.google.gwt.json.client), and the names don't overlap, so you can > > > stuff the new API into the old one without breaking existing code > > > using the old API. If you only use one of the two APIs, the other one > > > gets eliminated during compilation. (I confirmed this). > > > > NB: I checked the 'safe' javascript json parser from json.org and they > > > use the same strategy of first extensively verifying the input then > > > just eval()ing it. I've nicked some of their extra safety code > > > including a bunch of characters, including in the higher unicode > > > ranges, that potentially get parsed as quotes or newlines or other > > > potentially dubious characters. > > > > NB2: Part of the idea of this API is that a server-side version is > > > released in tandem with this client side version. This should probably > > > become a separate jar, I guess? Any ideas on how to distribute that? > > > > NB3: I didn't test speed, but this version should be similarly fast. > > > The main speed boost of the old library: Lazy java-ification of the > > > values, is preserved in the new API. The new API re-walks the tree on > > > every lookup whereas the old one doesn't, but the new one uses a lot > > > more JSO overlay, so I doubt there's a significant difference either > > > way. The parsing bit is slower, but that's because of the safety > > > measures. > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
