# NMath User's Guide

1.9 Very Large Objects (.NET, C#, CSharp, VB, Visual Basic, F#)

By default, the .NET runtime limits the size of any one object to 2 GB. For example, a matrix is limited to a theoretical maximum of 402,653,184 doubles or 805,306,368 floats —such as a 20,066 x 20,066 square DoubleMatrix or a 28,377 x 28,377 square FloatMatrix. With the release of .NET 4.5, developers can now create objects that exceed this limit by enabling gcAllowVeryLargeObjects in the run-time schema (x64 only), which controls the behavior of the .NET garbage collection system.

```<configuration>
<runtime>
<gcAllowVeryLargeObjects enabled="true" />
</runtime>
</configuration>
```

Very large objects are subject to the following restrictions:

The maximum number of elements in an array is UInt32.MaxValue.

The maximum index in any single dimension is 2,147,483,591 (0x7FFFFFC7) for byte arrays and arrays of single-byte structures, and 2,146,435,071 (0X7FEFFFFF) for other types.

The maximum size for strings and other non-array objects is unchanged.

http://msdn.microsoft.com/en-us/library/hh285054%28v=vs.110%29.aspx

Underlying all NMath vectors and matrices is a contiguous 1D array called a data block (Chapter 4). Thus, the number of elements for vectors or matrices must be less than 2,146,435,071. Table 2 summarizes the maximum size of various NMath objects under .NET 4.5 on a x64 OS with gcAllowVeryLargeObjects enabled.

 Class Maximum size (elements) Memory size (GBytes) FloatVector 2,146,435,071 7.996 DoubleVector 2,146,435,071 15.992 FloatMatrix 2,146,435,071 7.996 DoubleMatrix 2,146,435,071 15.992

The complex versions of these classes have the same maximum number of elements but occupy twice the memory.

To use gcAllowVeryLargeObjects, you must target .NET 4.5.

Very Large Objects with ASP.NET

The gcAllowVeryLargeObjects flag can only be set per-process, and only when the CLR is initializing. It cannot be set in the application-level Web.config file, because the CLR is already initialized by the time that file is read.

The workaround is to specify a CLRConfigFile in the aspnet.config file in the .NET framework installation. This little-known file is used to specify startup flags for both ASP.NET and CLR for those settings that are needed very early in the worker process lifetime, when the configuration system is not yet present.

Using CLRConfigFile allows you to specify an intermediate configuration file that the CLR can use for initialization. Once the CLR is up, ASP.NET will read your Web.config and run your application as normal.