Why TList uses a lot more memory than TArray?

[Fr0sT.Brutal 900]

1 minute ago, David Heffernan said:

I have no qualms about working with a 2G memory block under 64 bit. What exactly are you getting at? Can you explain in technical terms what problem you envisage? 

My point is trivial. If there's no available RAM for expanding a 1G array (that is, 2G) and swap file is limited/disabled as well, this action will fail. Moreover, falling to swap could be unacceptable due to perf degradation. Moremoreover (huh), Windows is very strict in guarding a leftover of free memory and keeps throwing warnings even when 1G left; on 0.5G free space it just kills the main consumer.

So doesn't matter whether the system is x64 or x128, available memory is limited.

[David Heffernan 2345]

22 minutes ago, Fr0sT.Brutal said:

So doesn't matter whether the system is x64 or x128, available memory is limited.

Flip side, you can have loads of available memory but no available contiguous address space. That's the advantage of a 64 bit process. It removes the limitations on address space. 

[Fr0sT.Brutal 900]

6 hours ago, David Heffernan said:

Flip side, you can have loads of available memory but no available contiguous address space. That's the advantage of a 64 bit process. It removes the limitations on address space. 

Indeed. Very big relief for memory-consuming apps

[Andrea Raimondi 13]

Try setting "Capacity" to a proper value. 

What I usually do is to load things in a TList<T> (or other such, for instance TObjectList<T>) then pass it over to an array with .ToArray .

By setting Capacity, you should be able to improve the memory size. I know because I used this very technique in the high-speed parsing of thousands of lines per text file in a situation where you may have hundreds or thousands of them per day (the format was weird and I can't really delve into the details, NDA). But it absolutely works. 

If the design allows it, you could even recycle the TList<T> with a clear so that you don't have to allocate many of them.