-2

Does this piece of code take a lot of memory space because of using the new keyword multiple times?

private static LinkedList<String> removeDuplicates(LinkedList<String> linkedList) {
    return new LinkedList<>(new HashSet<>(linkedList));
}
Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
Saloh
  • 1
  • 3
  • General answer: no, returning a "new" object like this is not a memory concern. In this case, if the input list contains many elements, there might be some concern, but the first concern should be that the code is correct. Memory comes second. – markspace Dec 28 '20 at 03:14
  • It really depends on the size of the collection and the duration of it. Garbage collector would remove unused objects in normal situations but, if your code does not handle your collection in an appropriate way, it can easily run out of memory. – MNEMO Dec 28 '20 at 03:18
  • 1
    [You shouldn't specify `LinkedList`](https://stackoverflow.com/questions/383947/what-does-it-mean-to-program-to-an-interface), and in fact you'll use a lot less memory if you use `ArrayList` as your return value. – chrylis -cautiouslyoptimistic- Dec 28 '20 at 03:23

2 Answers2

1

I think you are thinking about this the wrong way.

From a technical perspective, while new does cause memory to be allocated, you cannot say how much is used just by counting new statements. It depends more on the type of object that you are allocating, and on what the constructor does.

For example:

  • new HashSet<>(linkedList) populates the hash set with the elements of the list. The memory used depends on the number of unique elements in the set.

  • new LinkedList<>(someCollection) populates the linked list with the elements of the collection. The memory used depends on the number of elements in the collection.

  • new ArrayList<>(someCollection) populates the array list with the elements of the collection. The memory used depends on the number of elements in the collection, but it is significantly less than LinkedList or HashSet.

Then we need to consider the lifetime of the objects. In your example, no references for the intermediate HashSet are kept so (unless it is huge) it will be reclaimed next time there is a minor garbage collection.

The overheads of allocation / collection are much smaller for objects that do not survive the first garbage collection.

So what can we learn?

  1. It is hard to generalize about the impact of memory allocation.

  2. Choice of data structures can be more important than counting new.

  3. Since Java is designed from the ground up to be garbage collected, it is not productive to obsess over how much memory is "used". Especially, not until you have a good feel for the language, the libraries, and the way that the garbage collectors work. If you try to fight the language, your code will most likely be complicated, and you may end up with unexpected performance and other issues; e.g. if you try "object pooling".

  4. Even when you do have a good feel for these things, it is (IMO) better to use a memory profiler, etc to identify places where your code's memory allocation patterns are profligate.

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I agree on above terms. The question came that I really had to use those 2 collections for some quick code update and need to identify the impact. Thanks much! – Saloh Dec 28 '20 at 05:39
0

It makes 2 copies. Does that 'badly affect' memory? Well, if you have a list with 4 billion items, and you run it though this, you need about 8GB worth at least. If you run a list of 50 items through it, who cares?

More to the point, why are you doing this?

The ordering is completely ruined when you do this, as HashSet does not maintain order. LinkedList is almost always wrong (it has theoretical performance gains over arraylist. These theoretical gains are essentially never actually realized on actual PC hardware; on the contrary, it's dog slow. Just use ArrayList), and if you wanted uniqueness, why not start out with HashSet right from the start?

rzwitserloot
  • 85,357
  • 5
  • 51
  • 72