1

I have a JSF grid type component where each cell is individually editable and the data for each cell is contained in a POJO called DataObject(DO) . The structure of DO is like this :

public class DO {

 //Id should be the coordinate. eg x@y . x is the row position and y is the column  position
 private String id;
 //This is value that goes to the client after applying formatter
 private Object value;
 //flag to indicate whether the cell will be disabled
 private boolean disabled;
 //flag to indicate whether the cell will be rendered
 private boolean rendered=true;
//Editor type for the cell
private String editorType;

}

So basically id field identifies the cell position(row and column) in the grid.

Now in our case we can have a 1000 row X 100 column grid where the grid itself is sparsely populated initially meaning that most of the cells do not contain any DO intially. So about 30% of those cells will contain data and the rest will not contain any data. I need to pass the data in JSON format from the server to the client javascript via ajax. The idea is to iterate through the collection of DO's and construct the JSON String .

So the JSON for a grid that has data for two cells would look something like this :

{
  id1 : {
  editorType:'InputEditor',
  value:'1234123',
  disabled:'false',
  rendered:'true'
  },

 id2 : {
 editorType:'SomeCustomEditor',
 value:'23456',
 disabled:'true',
 rendered:'true'
  }
 }

What existing JSON Java library can I use here to produce this output JSON in the most efficient way ? Any example code will help here .

Inquisitive
  • 7,476
  • 14
  • 50
  • 61
  • @StephenC as I wrote in the question , the number of DataObjects will will be way lesser than the number of cells. – Inquisitive Jul 11 '12 at 13:55
  • @StephenC that is the most extreme case I can think of and would be rare. In most cases we have to deal with sane amount of data . BTW what are the other options apart from JSON here ? – Inquisitive Jul 11 '12 at 14:00
  • Do you need to load all the rows at once? Most data grid components should support loading additional data via AJAX. – millimoose Jul 11 '12 at 14:10
  • @millimoose loading all rows initially is not a must here .We can ofcourse use ajax loading policy. – Inquisitive Jul 11 '12 at 14:12
  • 1
    If you've already got this working with JSON, you might look at [MsgPack](http://msgpack.org/). It's essentially "binary JSON" and should shave off some data overhead without having to recode everything for a different serialisation format / metaphor. – millimoose Jul 11 '12 at 15:45
  • @millimoose +1 for mentioning about MsgPack . I will give it a shot and see how it goes. – Inquisitive Jul 11 '12 at 16:10
  • @Downvoter care to explain the reason for downvote? – Inquisitive Jul 12 '12 at 06:45

2 Answers2

4

I have tested many (to/from) JSON parser for a very high speed messaging process, App had to send 200*100 messages per second. Since the UI was JavaScript (and websocket) -- we decided to use JSON. We started with JSONObject -- an it failed miserably.

I do not have numbers off my head but here is the relative speed of these APIs:
(fastest) Jackson > Gson >>> JSONObject (slowest)

  1. Jackson
  2. Gson
  3. JSONObject

We planned to evaluate json-smart, but got decent performance with Jackson -- so stopped. If you are on to it and planning to run a benchmark. Do include this. The only issue that we observed is this does not seem very popular, so we hesitated to use it to avoid a corner corner case failure which no body listens to.

Nishant
  • 54,584
  • 13
  • 112
  • 127
  • I think for now I will go with jackson , how do we exclude fields from the serialization or rather include only some fields into the serialization process ?actually the DataObject class has many more fields but I want to serialize only the four fields that I mentioned in the original question. – Inquisitive Jul 11 '12 at 15:07
  • see [Every day Jackson usage, part 3: Filtering properties](http://www.cowtowncoder.com/blog/archives/2011/02/entry_443.html) – Nishant Jul 11 '12 at 15:34
  • +1 for mentioning which is the fastest that you have seen . It helps in my case . thanks. – Inquisitive Jul 11 '12 at 16:00
0

For that much data, you should consider using something other than JSON.

  • You could roll your own binary format; e.g. 4 bytes for the number, 1 byte for the 2 flags and a code number for the editor type, and 1 byte each for each character of the id.

  • You could use Google protobufs. This will give you a compact binary format and generated message parsers and unparsers in a number of languages.

Your JSON coding of the data is roughly 90 bytes per non-empty cell, compared with maybe 15 per non-empty cell for a binary format. And the overheads of parsing and unparsing will be much less.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • ultimately I need to pass this data to a javascript . How does Google protobufs help here ? Javascript can deal with json 's more efficiently than protobufs or am I missing something here ? – Inquisitive Jul 11 '12 at 14:21
  • Yes ... you are missing that sending 3Mb of data takes a significant time. Probably longer than the time taken to parse and unparse the JSON. – Stephen C Jul 11 '12 at 14:37
  • how is support for protobufs in javascript ? this is also an important consideration before proceeding further on this line – Inquisitive Jul 11 '12 at 14:39
  • I can't answer that from personal experience. However - http://stackoverflow.com/questions/7074147/protocol-buffers-for-javascript – Stephen C Jul 11 '12 at 14:43
  • 1
    +1 for mentioning about Google protobuffs .But JS support seems dodgy at the moment. So I will go the JSON way . BUT it really looks promising and I hope they come with better JS support soon. – Inquisitive Jul 11 '12 at 15:58
  • Note, however, that it WILL NOT be faster from JS unless Javascript engine adds native support for decoding. JS engines generally have native JSON parsers. So it is not given that protobuf will make sense for such use case even in future. – StaxMan Jul 13 '12 at 19:04
  • On compactness: surprisingly good choice might be CSV; which would require simple parsing on JS, but since it's textual, that'd probably still be fast enough. And `Jackson` actually has alternate CSV backend as well (and there are n+1 other java libs too) – StaxMan Jul 13 '12 at 19:05