Does an empty array in .NET use any space?

Question

I have some code where I'm returning an array of objects.

Here's a simplified example:

string[] GetTheStuff() {
    List<string> s = null;
    if( somePredicate() ) {
        s = new List<string>(); // imagine we load some data or something
    }
    return (s == null) ? 
        new string[0] :
        s.ToArray();
}

The question is, how expensive is the new string[0] ?
Should I just return null and make the caller accept null as a valid way of indicating "nothing was found"?

NB: This is being called in a loop which gets run hundreds and hundreds of times, so it's one of the few cases where I think this kind of optimiziation is not actually 'premature'.

PS: And even if it was premature, I'd still like to know how it works :-)

Update:

Initially when I asked if it used any space, I was thinking of things from the 'C/C++' point of view, kind of like how in C, writing char a[5]; will allocate 5 bytes of space on the stack, and char b[0]; will allocate 0 bytes.

I realise this is not a good fit for the .NET world, but I was curious if this was something that the compiler or CLR would detect and optimize out, as a non-resizeable array of size zero really shouldn't (as far as I can see?) require any storage space.

Answer 1

I would guess that an empty array uses only the space needed to allocate the object pointer itself.

From memory the API guidelines say that you should always return an empty array from a method that returns an array rather than returning null, so I'd leave your code the way it is regardless. That way the caller knows he's guaranteed to get an array (even an empty one) and need not check for null with each call.

Edit: A link about returning empty arrays:

http://wesnerm.blogs.com/net_undocumented/2004/02/empty_arrays.html

Answer 2

Declared arrays will always have to contain the following information:

• Rank (number of dimensions)
• Type to be contained
• Length of each dimension

This would most likely be trivial, but for higher numbers of dimensions and higher lengths it will have a performance impact on loops.

As for return types, I agree that an empty array should be returned instead of null.

More information here: Array Types in .NET

Answer 3

If I understand correctly, a small amount of memory will be allocated for the string arrays. You code essentially requires a generic list to be created anyway, so why not just return that?

[EDIT]Removed the version of the code that returned a null value. The other answers advising against null return values in this circumstance appear to be the better advice[/EDIT]

List<string> GetTheStuff()
{
   List<string> s = new List<string();
   if (somePredicarte())
   {
      // more code
   }
   return s;
}

Answer 4

Even if it's being called "hundreds and hundreds" of times, I'd say it's a premature optimization. If the result is clearer as an empty array, use that.

Now for the actual answer: yes, an empty array takes some memory. It has the normal object overhead (8 bytes on x86, I believe) and 4 bytes for the count. I don't know whether there's anything beyond that, but it's not entirely free. (It is incredibly cheap though...)

Fortunately, there's an optimization you can make without compromising the API itself: have a "constant" of an empty array. I've made another small change to make the code clearer, if you'll permit...

private static readonly string[] EmptyStringArray = new string[0];

string[] GetTheStuff() {
    if( somePredicate() ) {
        List<string> s = new List<string>(); 
        // imagine we load some data or something
        return s.ToArray();
    } else {
        return EmptyStringArray;
    }
}

If you find yourself needing this frequently, you could even create a generic class with a static member to return an empty array of the right type. The way .NET generics work makes this trivial:

public static class Arrays<T> {
    public static readonly Empty = new T[0];
}

(You could wrap it in a property, of course.)

Then just use: Arrays<string>.Empty;

EDIT: I've just remembered Eric Lippert's post on arrays. Are you sure that an array is the most appropriate type to return?

Answer 5

This is not a direct answer to your question.

Read why arrays are considered somewhat harmful. I would suggest you to return an IList<string> in this case and restructure the code a little bit:

IList<string> GetTheStuff() {
    List<string> s = new List<string>();
    if( somePredicate() ) {
        // imagine we load some data or something
    }
    return s;
}

In this way the caller doesn't have to care about empty return values.

---

EDIT: If the returned list should not be editable you can wrap the List inside a ReadOnlyCollection. Simply change the last line to. I also would consider this best practice.

    return new ReadOnlyCollection(s);

Answer 6

Yes, as others have said, the empty array takes up a few bytes for the object header and the length field.

But if you're worried about performance you're focusing on the wrong branch of execution in this method. I'd be much more concerned about the ToArray call on the populated list which will result in a memory allocation equal to its internal size and a memory copy of the contents of the list into it.

If you really want to improve performance then (if possible) return the list directly by making the return type one of: List<T>, IList<T>, ICollection<T>, IEnumerable<T> depending on what facilities you need from it (note that less specific is better in the general case).

Answer 7

Others have answered your question nicely. So just a simple point to make...

I'd avoid returning an array (unless you can't). Stick with IEnumerable and then you can use Enumerable.Empty<T>() from the LINQ APIs. Obviously Microsoft have optimised this scenario for you.

IEnumerable<string> GetTheStuff()
{
    List<string> s = null;
    if (somePredicate())
    {
        var stuff = new List<string>();
        // load data
        return stuff;
    }

    return Enumerable.Empty<string>();
}