下面是System.Collections.BitArray的另一个方法，它有这样的构造函数。

bool[] result = new BitArray(1000000, true).Cast<bool>().ToArray();

or

bool[] result = new bool[1000000];
new BitArray(1000000, true).CopyTo(result, 0);

对于大型数组或可变大小的数组，您可能应该使用:

Enumerable.Repeat(true, 1000000).ToArray();

对于小数组，你可以使用c# 3中的集合初始化语法:

bool[] vals = new bool[]{ false, false, false, false, false, false, false };

集合初始化语法的好处是，不必在每个槽中使用相同的值，可以使用表达式或函数初始化一个槽。另外，我认为您避免了将数组槽初始化为默认值的代价。举个例子:

bool[] vals = new bool[]{ false, true, false, !(a ||b) && c, SomeBoolMethod() };

我不知道框架方法，但你可以写一个快速助手来帮你做。

public static void Populate<T>(this T[] arr, T value ) {
  for ( int i = 0; i < arr.Length;i++ ) {
    arr[i] = value;
  }
}

这里给出的许多答案都可以归结为一个循环，每次初始化数组中的一个元素，它没有利用设计为一次操作内存块的CPU指令。

. net Standard 2.1(在撰写本文时的预览版中)提供了Array.Fill()，这有助于在运行时库中实现高性能(尽管到目前为止，. net Core似乎还没有利用这种可能性)。

For those on earlier platforms, the following extension method outperforms a trivial loop by a substantial margin when the array size is significant. I created it when my solution for an online code challenge was around 20% over the allocated time budget. It reduced the runtime by around 70%. In this case, the array fill was performed inside another loop. BLOCK_SIZE was set by gut feeling rather than experiment. Some optimizations are possible (e.g. copying all bytes already set to the desired value rather than a fixed-size block).

internal const int BLOCK_SIZE = 256;
public static void Fill<T>(this T[] array, T value)
{
    if (array.Length < 2 * BLOCK_SIZE)
    {
        for (int i = 0; i < array.Length; i++) array[i] = value;
    }
    else
    {
        int fullBlocks = array.Length / BLOCK_SIZE;
        // Initialize first block
        for (int j = 0; j < BLOCK_SIZE; j++) array[j] = value;
        // Copy successive full blocks
        for (int blk = 1; blk < fullBlocks; blk++)
        {
            Array.Copy(array, 0, array, blk * BLOCK_SIZE, BLOCK_SIZE);
        }

        for (int rem = fullBlocks * BLOCK_SIZE; rem < array.Length; rem++)
        {
            array[rem] = value;
        }
    }
}

创建一个包含1000个真值的新数组:

var items = Enumerable.Repeat<bool>(true, 1000).ToArray();  // Or ToList(), etc.

类似地，你可以生成整数序列:

var items = Enumerable.Range(0, 1000).ToArray();  // 0..999

下面是另一个被微软抛弃的版本。它的速度是Array的4倍。比Panos Theof的解决方案和Eric J和Petar Petrov的并行解决方案更清晰和更快——对于大型阵列，速度可达两倍。

首先，我想向您介绍函数的祖先，因为这样更容易理解代码。在性能方面，这与Panos Theof的代码相当，对于某些事情来说可能已经足够了:

public static void Fill<T> (T[] array, int count, T value, int threshold = 32)
{
    if (threshold <= 0)
        throw new ArgumentException("threshold");

    int current_size = 0, keep_looping_up_to = Math.Min(count, threshold);

    while (current_size < keep_looping_up_to)
        array[current_size++] = value;

    for (int at_least_half = (count + 1) >> 1; current_size < at_least_half; current_size <<= 1)
        Array.Copy(array, 0, array, current_size, current_size);

    Array.Copy(array, 0, array, current_size, count - current_size);
}

如您所见，这是基于已初始化部分的重复加倍。这是简单而有效的，但它与现代内存架构相冲突。因此诞生了一个版本，它只使用加倍来创建一个缓存友好的种子块，然后在目标区域迭代地爆破:

const int ARRAY_COPY_THRESHOLD = 32;  // 16 ... 64 work equally well for all tested constellations
const int L1_CACHE_SIZE = 1 << 15;

public static void Fill<T> (T[] array, int count, T value, int element_size)
{
    int current_size = 0, keep_looping_up_to = Math.Min(count, ARRAY_COPY_THRESHOLD);

    while (current_size < keep_looping_up_to)
        array[current_size++] = value;

    int block_size = L1_CACHE_SIZE / element_size / 2;
    int keep_doubling_up_to = Math.Min(block_size, count >> 1);

    for ( ; current_size < keep_doubling_up_to; current_size <<= 1)
        Array.Copy(array, 0, array, current_size, current_size);

    for (int enough = count - block_size; current_size < enough; current_size += block_size)
        Array.Copy(array, 0, array, current_size, block_size);

    Array.Copy(array, 0, array, current_size, count - current_size);
}

注意:前面的代码需要(count + 1) >> 1作为加倍循环的限制，以确保最终的复制操作有足够的素材来覆盖所有剩余的内容。如果使用计数>> 1来代替奇数，则不会出现这种情况。对于当前版本，这是没有意义的，因为线性复制循环将弥补任何懈怠。

数组单元格的大小必须作为参数传递，因为——令人难以置信的是——泛型不允许使用sizeof，除非它们使用一个约束(非托管)，这个约束将来可能可用，也可能不可用。错误的估计不是什么大问题，但如果值是准确的，性能是最好的，原因如下:

低估元素大小可能导致块大小超过L1缓存的一半，因此增加了从L1中删除复制源数据的可能性，并且必须从较慢的缓存级别重新获取。 高估元素大小会导致CPU L1缓存利用率不足，这意味着线性块复制循环的执行次数比最佳利用率时要多。因此，产生的固定循环/调用开销比严格需要的要多。

下面是我的代码与Array的一个基准测试。清除和前面提到的其他三个解决方案。计时用于填充给定大小的整数数组(Int32[])。为了减少缓存异常等引起的变化，每个测试执行两次，背靠背，并在第二次执行时进行计时。

array size   Array.Clear      Eric J.   Panos Theof  Petar Petrov   Darth Gizka
-------------------------------------------------------------------------------
     1000:       0,7 µs        0,2 µs        0,2 µs        6,8 µs       0,2 µs 
    10000:       8,0 µs        1,4 µs        1,2 µs        7,8 µs       0,9 µs 
   100000:      72,4 µs       12,4 µs        8,2 µs       33,6 µs       7,5 µs 
  1000000:     652,9 µs      135,8 µs      101,6 µs      197,7 µs      71,6 µs 
 10000000:    7182,6 µs     4174,9 µs     5193,3 µs     3691,5 µs    1658,1 µs 
100000000:   67142,3 µs    44853,3 µs    51372,5 µs    35195,5 µs   16585,1 µs 

如果这段代码的性能不够，那么一个有希望的途径将是并行线性复制循环(所有线程使用相同的源块)，或者我们的老朋友P/Invoke。

Note: clearing and filling of blocks is normally done by runtime routines that branch to highly specialised code using MMX/SSE instructions and whatnot, so in any decent environment one would simply call the respective moral equivalent of std::memset and be assured of professional performance levels. IOW, by rights the library function Array.Clear should leave all our hand-rolled versions in the dust. The fact that it is the other way around shows how far out of whack things really are. Same goes for having to roll one's own Fill<> in the first place, because it is still only in Core and Standard but not in the Framework. .NET has been around for almost twenty years now and we still have to P/Invoke left and right for the most basic stuff or roll our own...