Date parsed: 05/10/2007 15:50:17
Date: Fri, 5 Oct 2007 13:50:17 +0200
"Willy Denoyette [MVP]" <willy.denoyette@telenet.be> ha scritto nel
messaggio news:egDSYEzBIHA.5960@TK2MSFTNGP05.phx.gbl...
> "Laura T." <LT_stop@yahoo.com> wrote in message
> news:en9rxiyBIHA.5980@TK2MSFTNGP04.phx.gbl...
>>
>> "Jon Skeet [C# MVP]" <skeet@pobox.com> ha scritto nel messaggio
>> news:MPG.216f51e3def198cb4f7@msnews.microsoft.com...
>>> Laura T. <LT_stop@yahoo.com> wrote:
>>>
>>> <snip>
>>>
>>>> The unfortunate thing with List<T> is that the capacity does grow up
>>>> one by
>>>> one. I'd like to see something like "expand it by 10%", so that the
>>>> next Add
>>>> would not incur reallocations.
>>>
>>> Nope, it doubles the capacity each time, as Doug said. Here's code to
>>> show that:
>>
>> Yes, you are right of course. I was thinking another thing. Oh well...
>> happens.
>>
>>>
>>> using System;
>>> using System.Collections.Generic;
>>>
>>> public class ConvertFile
>>> {
>>> public static void Main(string[] args)
>>> {
>>> List<string> list = new List<string>();
>>>
>>> int previousCapacity=-1;
>>> for (int i=0; i < 100000; i++)
>>> {
>>> list.Add("");
>>> if (list.Capacity != previousCapacity)
>>> {
>>> Console.WriteLine (list.Capacity);
>>> previousCapacity = list.Capacity;
>>> }
>>> }
>>> }
>>> }
>>>
>>> Output:
>>>
>>> 4
>>> 8
>>> 16
>>> 32
>>> 64
>>> 128
>>> 256
>>> 512
>>> 1024
>>> 2048
>>> 4096
>>> 8192
>>> 16384
>>> 32768
>>> 65536
>>> 131072
>>>
>>> It would perhaps be nice to be able to specify the scaling factor, but 2
>>> is reasonable for most situations.
>> Reasonable and fast, yes. A hack but reasonable one. It's still strange,
>> and maybe unfortunate, that the doubling behavior does not seem to be
>> documented.
>> The current wording
>> (http://msdn2.microsoft.com/en-us/library/y52x03h2.aspx) "If Count
>> exceeds Capacity while adding elements, the capacity is increased by
>> automatically reallocating the internal array before copying the old
>> elements and adding the new elements." is misleading.
>>
>> Still, it's not that hard to roll your own capacity calculator by
>> deriving a new class from List<T> and overriding the needed methods.
>> It's not beautiful because it needs to hide methods (new) but it can be
>> done. For many some applications, more linear allocation helps
>> performance.
>>
>>>
>>>
>>> --
>>> Jon Skeet - <skeet@pobox.com>
>>>
http://www.pobox.com/~skeet Blog:
http://www.msmvps.com/jon.skeet>>> If replying to the group, please do not mail me too
>>
>
>
> The scaling factor is not documented because it's an implementation
> detail, MSFT reserves the right to change the factor statically and
> dynamically, something they were thinking of (if not yet done in V3.5)
> for MSIL code that runs on X64/IA64.
>
> Willy.
Let me disagree.
IMHO, any behavior that may have a impact on the resource consumption model
of my application deserves to be documented.
Microsoft may well write "This behavior may change in the future". There is
nothing wrong with it. Good. Go and optimize it. Make it better.
Knowing that the array doubles is key parameter to understand better
memory/performance behavior of my code.
And, already, Microsoft documents implementation details with O(1), O(N)
etc. Even they can change in the future.
But as I said, it's my opinion.
