osdir.com
mailing list archive F.A.Q. -since 2001!



Subject: [ANN] JSONKit - Yet another JSON library -
msg#00992

List: cocoa-dev

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

Announcing JSONKit - http://github.com/johnezang/JSONKit A BSD Licensed
JSON serializer / deserializer.

Yes, yet another JSON library for Cocoa / Objective-C. Why another JSON
library? Well, if you assume that all the JSON libraries offer similar
functionality, that leaves one major metric that you can improve on: Speed.
And that's the metric JSONKit is aimed at. As an example, using the Sam
Soffes JSON benchmarks (
http://samsoff.es/posts/updated-iphone-json-benchmarks ,
http://github.com/samsoffes/json-benchmarks), I get the following results
when running on the iPhone simulator:

[Session started at 2010-07-30 08:57:06 -0400.]

*2010-07-30 08:57:08.431 JSONBenchmarks[754:207] Starting benchmarks with
100 iterations for each library*

*2010-07-30 08:57:09.257 JSONBenchmarks[754:207] TouchJSON average read
time : 0.003940*

*2010-07-30 08:57:10.344 JSONBenchmarks[754:207] TouchJSON average write
time : 0.009265*

*2010-07-30 08:57:10.967 JSONBenchmarks[754:207] JSON Framework average read
time : 0.002701*

*2010-07-30 08:57:11.182 JSONBenchmarks[754:207] JSON Framework average
write time: 0.002077*

*2010-07-30 08:57:11.709 JSONBenchmarks[754:207] YAJL average read time
: 0.001834*

*2010-07-30 08:57:11.997 JSONBenchmarks[754:207] YAJL average write time
: 0.002652*

*2010-07-30 08:57:12.508 JSONBenchmarks[754:207] Apple JSON average read
time : 0.001746*

*2010-07-30 08:57:12.713 JSONBenchmarks[754:207] Apple JSON average write
time : 0.001975*

*2010-07-30 08:57:13.109 JSONBenchmarks[754:207] JSONKit average read
time : 0.000591*

*2010-07-30 08:57:13.157 JSONBenchmarks[754:207] JSONKit average write
time : 0.000460*

*2010-07-30 08:57:13.157 JSONBenchmarks[754:207] Done. Quitting...*

*
*
JSONKit manages to turn in some pretty impressive times relative to the
other solutions. Benchmarks should always be taken with a grain of salt,
but I'm fairly confident that JSONKit will beat the current crop of
Objective-C JSON solutions out there. If you're going to do some
benchmarking of your own, I'd recommend using "-O3 -DNS_BLOCK_ASSERTIONS"
for maximum performance.

One of the ways that JSONKit manages to improve "read" (i.e., deserialize
UTF8 JSON text in to Objective-C objects) times is by keeping a small cache
of recent object conversions. This is particularly effective for JSON key /
value dictionaries where the keys tend to repeat. Another advantage of
using a cache is that it reduces the amount of memory required for the final
Objective-C representation of the serialized JSON because an object is
instantiated only once and reused again and again.

Now, despite the obvious improvements in speed, there are some drawbacks:

- JSONKit is new. Brand new. Days old as of this writing. This means
there's almost certainly bugs. While I've done my best at ad-hoc testing,
I've yet to crank out a comprehensive unit test harness for it.

- There's no documentation, so you're pretty much on your own. While I'm
capable of writing high quality documentation (see RegexKitLite, for
example), writing high quality documentation takes a long time to write,
usually 2-4 times longer than writing the code itself.

- The API is pretty basic. Actually, this is a bit of an understatement.
This reflects the current state of development which is focused more on the
internals than making use of its functionality. :) Feedback in this are is
appreciated.

- The guts are crufty C. Very crufty C. This reflects the primary
objective: speed. The idea is to provide a quality, very fast primitive
that can be used from the comfort of Objective-C. All the gory details are
hidden away. Normally I wouldn't recommend this kind of optimization to
anyone, but there are exceptions to every rule. I think there is a large
enough need for a JSON primitive that the extra effort is worth it in this
case.

- No support for garbage collection, and I doubt there ever will be.

Whether or not JSONKit continues on depends on the level of interest from
the community. Even if JSONKit "dies", it raises the bar in terms of
performance. A little competition can go a long way and hopefully this will
encourage the other JSON solutions out there to meet or beat the performance
of JSONKit. To that end, I openly encourage the authors of other JSON
solutions to study JSONKit and borrow anything from JSONKit that can improve
their solution.
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/maillists%40codeha.us

This email sent to maillists@xxxxxxxxx

Thread at a glance:

Previous Message by Date:

Question about a custom UITableView (possibly)

I've been asked about making a certain kind of control and I'm wondering what the best approach might be. The gist of the idea... something that looks like a UITableView, but when you select an item (that has more information behind it), it would select the row and animate expand the list item (height) to show a UIScrollView of buttons that can slide left/right. Once one of those is selected, a UITableView of items would be placed into that row related to the button selected. One could click the row header at any time to collapse the entire row of contents. Should this all be made extending a UIScrollView to begin with, and then place the necessary stuff into? Can a UITableView even approach handling the kind of interactions I've been asked about? Eric _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/maillists%40codeha.us This email sent to maillists@xxxxxxxxx

Next Message by Date:

Re: Cocoa-dev Digest, Vol 7, Issue 777

On Jul 29, 2010, at 5:59 PM, Martin Stanley wrote: >> Even if you could capture a proposed deletion before save, which AFAIK you >> can't, you will still have an undo mess. IMHO you best bet is to capture the >> situation at the point of editing the predicate, substituting the deleted >> item with a placeholder like "<deleted>". > I agree, trying to capture the deletion would be an unholy mess. > > But perhaps I haven't explained the problem clearly enough. The problem > arises not when the predicate is being edited, but when entity referenced in > the predicate is deleted. I need to find a way to notice this and then to > take corrective action. > > Also, it would be nice to let the user know that the deletion of this entity > will invalidate a SmartGroup. Once the model is changed appropriately I can > perform this check in response to the user request to delete the entity. I was assuming that your language use was loose, but do you *really* mean deleting an entity, or simply deleting a managed object of that entity type? The former would be a horribly bad idea in most cases. Assuming that you don't mean the above, I still don't think you are articulating the problem correctly. Deleting isn't the problem--Core data does that just fine. It seems that it is some *consequence* of the deletion that is the problem. What is that precisely? That a "smart group" will be invalid? Unless you present it otherwise to the user, it is just a predicate, and it is just as valid if it doesn't match anything. But then if the problem is that you don't want this condition to occur without user consent--which may be a friendly feature--as long as project objects can't be deleted by core data internal processes (such as the result of a delete rule), you have complete control over the deletion, so you can check it then, before it even occurs. Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/maillists%40codeha.us This email sent to maillists@xxxxxxxxx

Previous Message by Thread:

Question about a custom UITableView (possibly)

I've been asked about making a certain kind of control and I'm wondering what the best approach might be. The gist of the idea... something that looks like a UITableView, but when you select an item (that has more information behind it), it would select the row and animate expand the list item (height) to show a UIScrollView of buttons that can slide left/right. Once one of those is selected, a UITableView of items would be placed into that row related to the button selected. One could click the row header at any time to collapse the entire row of contents. Should this all be made extending a UIScrollView to begin with, and then place the necessary stuff into? Can a UITableView even approach handling the kind of interactions I've been asked about? Eric _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/maillists%40codeha.us This email sent to maillists@xxxxxxxxx

Next Message by Thread:

IKImageView choppy?

I have an IKImageView, and I'm putting CGImages (That I make out of NSImages) onto it. However, a normal 200DPI 8.5/11 page takes like 3 seconds to come up, appearing in rectangles about 2inches (screen) on a side at a time. This is really annoying. Is there a way around this? Alternatively, is there a way to double buffer the view? To have 2 IKImageViews and draw into one, and then display it? Brian Postow Senior Software Engineer Acordex Imaging Systems _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@xxxxxxxxxxxxxxx) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/maillists%40codeha.us This email sent to maillists@xxxxxxxxx
blog comments powered by Disqus

Home | News | Sitemap | FAQ | advertise | OSDir is an Inevitable website. GBiz is too!