I am wondering about the performance of Java HashMap vs JSONObject.
It seems JSONObject stores data internally using HashMap. But JSONObject might have additional overhead compared to HashMap.
Does any one know about the performance of Java JSONObject compared to HashMap?
Thanks!
As you said, JSONObject is backed by a HashMap.
Because of this, performance will be almost identical. JSONObject.get() adds a null check, and will throw an exception if a key isn't found. JSONObject.put() just calls map.put().
So, there is almost no overhead. If you are dealing with JSON objects, you should always use JSONObject over HashMap.
I would say the question doesn't make sense for a few reasons:
Comparing apples to oranges: HashMap and JSONObject are intended for 2 completely different purposes. It's like asking "is the Person class or Company class more efficient for storing a PhoneNumber object". Use what makes sense.
If you are converting to/from JSON, you are likely sending the data to a far away place (like a user's browser). The time taken to send this data over the network and evaluate it in the user's browser will (likely) far eclipse any performance differences of populating a Hashmap or JSONObject.
There is more than 1 "JSONObject" implementation floating around out there.
Finally, you haven't asked about what sort of performance you would like to measure. What are you actually planning to do with these classes?
Existing answers are correct, performance differences between the two are negligible.
Both are basically rather inefficient methods of storing and manipulating data. More efficient method is typically to bind into regular Java objects, which use less memory and are faster to access. Many developers use org.json's simple (primitive) library because it is well-known, but it is possible the least convenient and efficient alternative available. Choices like Jackson and Gson are big improvements so it is worth considering using them.
JSONObject does not have too much additional overhead on top of a HashMap. If you are okay with using a HashMap then you should be okay using a JSONObject. This is provided you want to generate JSON.
JSONObject checks for validity of values that you are storing as part of your JSONObject, to make sure it conforms to the JSON spec. For e.g. NaN values do not form a part of valid JSON. Apart from this, JSONObject can generate json strings (regular | prettfied). Those strings can get pretty big, depending on the amount of JSON. Also, JSONObject uses StringBuffer, so one of the many things that i would do would be to replace all occurrences of StringBuffer with StringBuilder.
JSONObject (from org.json) is one of the simple JSON libraries that you can use. If you want something very efficient, use something like Jackson.
The only performance overhead is on casting data! As you JSONObject stores data on a HashMap of objects and it casts the datatype you want.
Related
Externalizable interface seems to be hard to use. Reasons
Strings in an object can be null. So, I have create and serialize flags to mentioned weather or not to do inReader.readUTF()
For Java Lists its even more hard.
I am not sure, what is the best way to externalize a java HashMap, since I would know at reading time, how many keys are there and if any value is null.
I want to understand the reason and/or core-logic for JSONObject is being an un-ordered set. Because in most of my cases there would be a request which needs response as a JSONObject in the order of time/position. After searching, I found lot of members telling to use JSONArray which I do not feel a good solution.
I want to get a clear idea before proceeding further.
Thank you in advance.
JSONObject is unordered because objects described by JSON are unordered, by specification:
An object is an unordered set of name/value pairs.
(Which is because JSON is derived from [is a subset of] JavaScript's object initializer syntax, and JavaScript objects are unordered — because there's no reason for the properties of an object to be ordered in the general case. That can be left to specializations of objects, like JavaScript's arrays, which are nothing more than objects with some special handling of property names, and associated array-like functions.)
The true, complete reason is only known by the members of the ECMA committee which finalized the ECMAScript specification since JSONObjects are a subset of JavaScript Objects; however, here is my guess.
To require that the properties of a JSON Object maintain a fixed order would likely add additional implementation overhead to a data structure which would otherwise be simpler without having that requirement. For example, a JSON object could be implemented as a simple hashtable; however, if the order of the properties was to remain fixed then an additional data structure would be required to list their order.
If JavaScript prescribed ordering of object properties, it would preclude the usage of hashtables in their implementation. On the other hand, why would an object's properties be ordered in the first place? It seems like an arbitrary constraint with, as we can see, far-reaching negative consequences.
I am writing a program that will be heavily reliant on ... something ... that stores data like an array where I am able to access any point of the data at any given time as I can in an array.
I know that the java library has an Array class that I could use or I could use a raw array[].
I expect that using the Array type is a bit easier to code, but I expect that it is slightly less efficient as well.
My question is, which is better to use between these two, and is there a better way to accomplish the same result?
Actually Array would be of no help -- it's not what you think it is. The class java.util.ArrayList, on the other hand, is. In general, if you can program with collection classes like ArrayList, do so -- you'll more easily arrive at correct, flexible software that's easier to read, too. And that "if" applies almost all the time; raw arrays are something you use as a last resort or, more often, when a method you want to call requires one as an argument.
The Array class is used for Java reflection and is very, very, rarely used.
If you want to store data in an array, use plain old arrays, indicated with [], or as Gabe's comment on the question suggests, java.util.ArrayList. ArrayList is, as your comment suggests easier to code (when it comes to adding and removing elements!!) but yes, is slightly less efficient. For variable-size collections, ArrayList is all but required.
My question is, which is better to use between these two, and is there a better way to accomplish the same result?
It depends on what you are trying to achieve:
If the number of elements in the array is known ahead of time, then an array type is a good fit. If not, a List type is (at least) more convenient to use.
The List interface offers a number of methods such as contains, insert, remove and so on that can save you coding ... if you need to do that sort of thing.
If properly used, an array type will use less space. The difference is particularly significant for arrays of primitive types where using a List means that the elements need to be represented using wrapper types (e.g. byte becomes Byte).
The Array class is not useful in this context, and neither is the Arrays class. The choice is between ArrayList (or some other List implementation class) and primitive arrays.
In terms of ease of use, the Array class is a lot easier to code.
The array[] is quite a problem in terms of the case that you need to know
the size of the list of objects beforehand.
Instead, you could use a HashMap. It is very efficient in search as well as sorting as
the entire process is carried out in terms of key values.
You could declare a HashMap as:
HashMap<String, Object> map = new HashMap<String, Object>();
For the Object you can use your class, and for key use the value which needs to be unique.
Sometime back our architect gave this funda to me and I couldn't talk to him more to get the details at the time, but I couldn't understand how arrays are more serializable/better performant over ArrayLists.
Update: This is in the web services code if it is important and it can be that he might mean performance instead of serializability.
Update: There is no problem with XML serialization for ArrayLists.
<sample-array-list>reddy1</sample-array-list>
<sample-array-list>reddy2</sample-array-list>
<sample-array-list>reddy3</sample-array-list>
Could there be a problem in a distributed application?
There's no such thing as "more serializable". Either a class is serializable, or it is not. Both arrays and ArrayList are serializable.
As for performance, that's an entirely different topic. Arrays, especially of primitives, use quite a bit less memory than ArrayLists, but the serialization format is actually equally compact for both.
In the end, the only person who can really explain this vague and misleading statement is the person who made it. I suggest you ask your architect what exactly he meant.
I'm assuming that you are talking about Java object serialization.
It turns out that an array (of objects) and ArrayList have similar but not identical contents. In the array case, the serialization will consist of the object header, the array length and its elements. In the ArrayList case, the serialization consists of the list size, the array length and the first 'size' elements of the array. So one extra 32 bit int is serialized. There may also be differences in the respective object headers.
So, yes, there is a small (probably 4 byte) difference in the size of the serial representations. And it is possible that an array can be serialized / deserialized
slightly more quickly. But the differences are likely to be down in the noise, and not worth worrying about ... unless profiling, etc tells you this is a bottleneck.
EDIT
Based on #Tom Hawtin's comment, the object header difference is significant, especially if the serialization only contains a small number of ArrayList instances.
Maybe he was refering to XML-serialization used in Webservices ?
Having used those a few years ago, I remember that a Webservice returning a List object was difficult to connect to (at least I could not figure it out, probably because of the inner structure of ArrayLists and LinkedLists), although this was trivially done when a native array was returned.
To adress Reddy's comment,
But in any case (array or ArrayList)
will get converted to XML, right?
Yes they will, but the XML-serialization basically translated in XML all the data contained in the serialized object.
For an array, that is a series of values.
For instance, if you declare and serialize
int[] array = {42, 83};
You will probably get an XML result looking like :
<array>42</array>
<array>83</array
For an ArrayList, that is :
an array (obviously), which may have a size bigger than the actual number of elements
several other members such as integer indexes (firstIndex and lastIndex), counts, etc
(you can find all that stuff in the source for ArrayList.java)
So all of those will get translated to XML, which makes it more difficult for the Webservice client to read the actual values : it has to read the index values, find the actual array, and read the values contained between the two indexes.
The serialization of :
ArrayList<Integer> list = new ArrayList<Integer>();
list.add(42);
list.add(83);
might end up looking like :
<firstIndex>0</firstIndex>
<lastIndex>2</lastIndex>
<E>42</E>
<E>83</E>
<E>0</E>
<E>0</E>
<E>0</E>
<E>0</E>
<E>0</E>
<E>0</E>
<E>0</E>
<E>0</E>
So basically, when using XML-serialization in Webservices, you'd better use arrays (such as int[]) than collections (such as ArrayList<Integer>). For that you might find useful to convert Collections to arrays using Collection#toArray().
They both serialize the same data. So I wouldn't say one is significantly better than the other.
As of i know,both are Serializable but using arrays is better coz the main purpose of implementing the ArrayList is for internal easy manipulation purpose,not to expose to outer world.It is little heavier to use ,so when using in webservices while serializing it ,it might create problems in the namespace and headers.If it automatically sets them ,you ll not be able to receive or send data properly.So it is better to use primitive arrays .
Only in Java does this make a difference, and even then it's hard to notice it.
If he didn't mean Java then yes, your best bet would most likely be asking him exactly what he meant by that.
Just a related thought: The List interface is not Serializable so if you want to include a List in a Serializable API you are forced to either expose a Serializable implementation such as ArrayList or convert the List to an array. Good design practices discourage exposing your implementation, which might be why your architect was encouraging you to convert the List to an array. You do pay a little time penalty converting the List to an array, but on the other end you can wrap the array with a list interface with java.util.Arrays.asList(), which is fast.
Given that Java ME allows for no reflection and is quite stripped down, what would a good approach to storing data in a RecordStore be? I thought of devising a JSON-like syntax adapter class which would probably require every class whose values are to be stored to implement a Hashtable + might probably require an additional regex library as even that's been taken away.
If you're wondering why on earth I need it, it's for an assignment. So the dilemma is really between writing a rather unnecessarily large chunk of proper code as a matter of principle or hardcoding everything in knowing nobody has to suffer through maintenance of this junk down the line. But, the good principles person in me is leaning towards the former.
EDIT: I should have elaborated — I'd like to store object's data within the RecordStore, so I'm trying to devise a method to represent an object as a string which can then be converted into a byte array.
For every object you want to save in the RecordStore, pare it down to its component Strings and primitives, then serialise it to a byte array, using a ByteArrayOutputStream wrapped in a DataOutputStream. Then write this byte array to RMS.
Reverse the process using a ByteArrayInputStream wrapped in a DataInputStream to get the object back.