[ACCEPTED]-Does an empty array in .NET use any space?-arrays

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

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

Fortunately, there's 13 an optimization you can make without compromising 12 the API itself: have a "constant" of 11 an empty array. I've made another small 10 change to make the code clearer, if you'll 9 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 8 frequently, you could even create a generic 7 class with a static member to return an 6 empty array of the right type. The way .NET 5 generics work makes this trivial:

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

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

Then just 3 use: Arrays<string>.Empty;

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

The upcoming version 4.6 of .NET (later 3 in 2015) contains a static method returning a length-zero 2 string[]:

Array.Empty<string>()

I suppose it returns the same instance 1 if called many times.

Declared arrays will always have to contain 7 the following information:

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

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

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

More information 1 here: Array Types in .NET

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

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

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

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

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

Edit: A 1 link about returning empty arrays:

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

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

I'd avoid 4 returning an array (unless you can't). Stick 3 with IEnumerable and then you can use Enumerable.Empty<T>() from 2 the LINQ APIs. Obviously Microsoft have 1 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>();
}

This is not a direct answer to your question.

Read 8 why arrays are considered somewhat harmful. I would suggest you to return an IList<string> in 7 this case and restructure the code a little 6 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 5 to care about empty return values.

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

    return new ReadOnlyCollection(s);

I know this is old question, but it's a 6 basic question and I needed a detailed answer.

So 5 I explored this and got results:

In .Net 4 when you create an array (for this example 3 I use int[]) you take 6 bytes before any memory is allocated 2 for your data.

Consider this code [In a 32 bit application!]:

int[] myArray = new int[0];
int[] myArray2 = new int[1];
char[] myArray3 = new char[0];

And 1 look at the memory:

myArray:  a8 1a 8f 70 00 00 00 00 00 00 00 00
myArray2: a8 1a 8f 70 01 00 00 00 00 00 00 00 00 00 00 00
myArray3: 50 06 8f 70 00 00 00 00 00 00 00 00

Lets explain that memory:

• Looks like the first 2 bytes are some kind of metadata, as you can see it changes between int[] and char[] (a8 1a 8f 70 vs 50 06 8f 70)
• Then it holds the size of the array in integer variable (little endian). so it's 00 00 00 00 for myArray and 01 00 00 00 for myArray2
• Now it's our precious Data [I tested with Immediate Window]
• After that we see a constant (00 00 00 00). I don't know what its meaning.

Now I feel a lot better about zero length array, I know how it works =]

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

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

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