Fix #1156: Unresolved import for builtin packages after reload #1496
Conversation
|
|
||
| _unknownType = new PythonType("Unknown", new Location(_moduleResolution.BuiltinsModule), string.Empty); | ||
| _builtinTypes[BuiltinTypeId.Unknown] = _unknownType; | ||
| return _unknownType; |
There was a problem hiding this comment.
Unknown type switched to lazy initialization
| /// <remarks>New in 2.2, moved in 3.3</remarks> | ||
| private static List<PythonLibraryPath> GetDefaultSearchPaths(IFileSystem fs, string library) { | ||
| var result = new List<PythonLibraryPath>(); | ||
| private static ImmutableArray<PythonLibraryPath> GetDefaultSearchPaths(IFileSystem fs, string library) { |
There was a problem hiding this comment.
Not entirely related to this PR, but I feel like we should come up with some agreement about which list types we're going to use across the board so we don't end up switching them back and forth between PRs...
There was a problem hiding this comment.
I am OK either way but I tend to use interfaces on public surface. Is there a benefit of Immutable over IReadOnly?
There was a problem hiding this comment.
There are 3 issues with IReadOnlyList<T>:
- It is read-only, but not immutable. If an object is provided to the outer context, but owner still has a reference to the object, the is no way to synchronize it anymore. E.g.:
If any code gets reference to the list through
private List<SomeType> _someList; public IReadOnlyList<SomeType> SomeList=> _someList;
SomeList, it still can be changed by the owner, concurrently to the reader. - Adding elements. With
ImmutableArray, adding elements create new instance of it, but it is as cheap as adding toList<T>. ForIReadOnlyList<T>, it requires to create a copy of the list. - Enumerator. For any interface, enumerator is an object. For
ImmutableArray<T>andList<T>it would be a struct. This becomes a problem when we haveforeachloops in analysis where enumerators are promoted to Gen2.
|
When I do the same memory testing I did for #1402, the memory usage after a big session or a reload doesn't seem to go down very much (or at all), and requires something else to happen to do another GC/compact for the memory to go down again. Maybe there's some timing problem where the new code is a bit faster and things aren't ready to be compacted yet, or something, but it might hurt memory usage. (Another case #1428 would help.) |
|
Just an example of what I'm describing:
There are variations where the initial install doesn't drop after its session GC/compact, and some where the reload GC/compact doesn't have any affect either. |
|
Here's what happens when I repeat the above but modify the ForceGC function to wait a bit:
private static void ForceGCIfNeeded(ILogger logger, int originalRemaining, int remaining, bool force) {
if (force || originalRemaining - remaining > 1000) {
Task.Run(async () => {
await Task.Delay(500);
logger?.Log(TraceEventType.Verbose, "Forcing full garbage collection and heap compaction.");
GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();
}).DoNotWait();
}
} |
…ad (microsoft#1496) * Fix microsoft#1156: Unresolved import for builtin packages after reload * Address CR comments
No description provided.