You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lists are often instantiated and immediately filled with items from a source having a known length, and it isn't always convenient to explicitly initialize the list with a capacity:
varlist=newList<TypeDesc>();foreach(var itfHandle in typeInfo.GetInterfaceImplementations()){// `C : IReadOnlyCollection<T>`// ...
list.Add(...);}returnlist;
This could be rewritten to a constructor call with the known capacity, or to a later call to EnsureCapacity(). The first is only possible if there aren't any side effects in between the ctor and source def.
This can be naturally generalized to lists that aren't freshly created. must make sure that calls to EnsureCapacity() always double the list's capacity to avoid +1 resizes that lead to O(n^2) complexity. (This is guaranteed by list.EnsureCapacity(list.Count + addCount))
There's another case where the items are added inline, and an upper-bound could be determined by counting the number of Add() calls instead of a loop bound.
Note that Add() calls behind if conditions are problematic because we don't know anything about them, so I'm not sure it would be a good idea to presize based on a static probability factor as that could end up pessimizing the code by allocating extra memory (but could still be worth for non-escaping lists with an ToArray() call at the end?).
Worklist
Detect for..i and foreach(collection) loops
Support for sources based on struct collections (ImmutableArray/Span)
LSR implements this by checking that the user chain of the struct address is non-escaping and not written inside the loop, which seems reasonable until/if we ever get proper infra like MemSSA.
Insert EnsureCapacity() calls and set count based on loops bounds
Replace add calls with direct array writes
Support for other known collections: ImmutableArray.Builder, Dictionary, HashSet, etc.
Add more tests
The text was updated successfully, but these errors were encountered:
Lists are often instantiated and immediately filled with items from a source having a known length, and it isn't always convenient to explicitly initialize the list with a capacity:
This could be rewritten to a constructor call with the known capacity, or to a later call to EnsureCapacity(). The first is only possible if there aren't any side effects in between the ctor and source def.
This can be naturally generalized to lists that aren't freshly created.
must make sure that calls to EnsureCapacity() always double the list's capacity to avoid +1 resizes that lead to O(n^2) complexity.(This is guaranteed bylist.EnsureCapacity(list.Count + addCount)
)There's another case where the items are added inline, and an upper-bound could be determined by counting the number of Add() calls instead of a loop bound.
Note that Add() calls behind if conditions are problematic because we don't know anything about them, so I'm not sure it would be a good idea to presize based on a static probability factor as that could end up pessimizing the code by allocating extra memory (but could still be worth for non-escaping lists with an ToArray() call at the end?).
Worklist
LSR implements this by checking that the user chain of the struct address is non-escaping and not written inside the loop, which seems reasonable until/if we ever get proper infra like MemSSA.
The text was updated successfully, but these errors were encountered: