티스토리 뷰

반응형

Visual Studio를 이용해서 대규모의 솔루션을 이용하면 성능 저하로 인하여 많은 어려움이 있었습니다. 이번에 Visual Studio 2019 16.8 버전에서 .NET 5 대규모 솔루션 개선 사항에 대한 포스팅이 나와서 살펴 보도록 하겠습니다.

Working with large .NET 5 solutions in Visual Studio 2019 16.8 | Visual Studio Blog (microsoft.com)

 

Working with large .NET 5 solutions in Visual Studio 2019 16.8 | Visual Studio Blog

With the release of .NET 5, migration of solutions from .NET Framework has increased. In particular, we have started to see very large solutions being moved. To ensure this experience is as good as possible, we have been working on optimizing Visual Studio

devblogs.microsoft.com

.NET 5가 출시됨에 따라 .NET Framework에서 솔루션 마이그레이션이 증가했습니다. 특히, 우리는 매우 큰 솔루션이 이동되는 것을 보기 시작했습니다. 이 경험을 가능한 한 좋게하기 위해 우리는 많은 수의 .NET 5 및 .NET Core 프로젝트가 포함 된 솔루션을 처리하도록 Visual Studio를 최적화하기 위해 노력해 왔습니다. 이러한 최적화 중 많은 부분이 16.8 릴리스에서 제공되었으며 이 블로그 게시물에서는 개선 된 사항을 설명합니다.

Running the C# and VB compiler out of process

C# 및 Visual Basic 컴파일러인 Roslyn은 IntelliSense, Go to Definition 및 진단/오류와 같은 서비스를 강화하기 위해 전체 솔루션을 구문을 분석합니다. 결과적으로 Roslyn은 개방형 솔루션의 크기에 비례하여 증가하는 리소스를 소비하는 경향이 있으며, 이는 대규모 솔루션에서 상당히 중요한 문제가 될 수 있습니다. Roslyn은 이미 즉시 필요하지 않은 디스크 정보를 적극적으로 캐싱하여 이러한 영향을 최소화하기 위해 노력했지만 이러한 캐싱을 사용해도 데이터를 메모리에 보관해야할 필요성을 피할 수 없습니다.

 

더 큰 Visual Studio 솔루션에 미치는 영향을 줄이기 위해 Roslyn 팀은 Roslyn 컴파일러를 Visual Studio 프로세스에서 자체 프로세스로 이동하는 데 상당한 노력을 기울였습니다. 자체 프로세스에서 Roslyn을 실행하면 Visual Studio 자체 내에서 리소스를 확보하고 Roslyn 컴파일러가 작업을 수행 할 수있는 더 많은 공간을 확보 할 수 있습니다. 대규모 솔루션의 경우 대규모 솔루션을 열 때 Visual Studio에서 사용하는 메모리의 최대 1/3을 절약 할 수 있습니다.

Streamlining the Dependencies node

모든 .NET 5 및 .NET Core 프로젝트에는 프로젝트가 의존하는 모든 항목 (다른 프로젝트, 어셈블리, NuGet 패키지 등)을 표시하는 "Dependencies"라는 이름의 솔루션 탐색기에 노드가 있습니다. 프로젝트에서 노드는 또한 프로젝트의 전 이적 종속성, 즉 각 종속성 자체가 의존하는 모든 것 등을 보여줍니다. 적당한 크기의 프로젝트를 사용하면 이 전이 종속성 목록이 상당히 커질 수 있습니다.

 

불행히도 "Dependencies"노드의 원래 구현은 메모리에 전이 종속성 정보를 저장하는 방식을 사용해서 효율적이지 않았습니다. 필요한 것보다 훨씬 많은 정보를 보유하고 있었고 많은 데이터가 중복되었습니다. 이번에 절대적으로 필요한 정보만 유지하도록 코드를 다시 작성했으며 NuGet에서 이미 유지한 종속성에 대한 기존 정보에 편승하기 시작했습니다. 이번 버전에서는 대규모 솔루션을 열 때 Visual Studio에서 사용하는 메모리의 최대 10-15 %를 절약했습니다.

Reducing duplicate information in MSBuild

Roslyn 다음으로 Visual Studio 프로세스에서 리소스의 다른 주요 소비자 중 하나는 MSBuild입니다. 이는 빌드 엔진으로서 대부분의 IDE 환경이 MSBuild의 개체 모델에 의해 구동되기 때문입니다. .NET 5 및 .NET Core에서 프로젝트 파일 자체를 훨씬 더 작게 만들었지 만 SDK를 통해 프로젝트로 가져 오는 지원 프로젝트 파일이 상당히 많습니다. 이러한 모든 파일을 평가하는 것은 프로젝트를 이해하고 빌드하는 데 필요하며 대규모 솔루션을 열 때 Visual Studio에서 사용하는 메모리의 최대 1/3을 소비 할 수 있습니다.

 

프로젝트 파일은 많은 양의 데이터를 생성하지만 대부분의 데이터는 반복적이며 메모리에서 해당 데이터의 중복 제거를 시작했습니다. 문자열은 프로젝트 시스템의 가장 일반적인 부산물 중 하나이며 파일 이름, 옵션 및 경로와 같은 정보를 저장합니다. 특히 경로는 상당히 길 수 있으며 경로가 너무 많거나 너무 많이 복제되면 결국 많은 메모리를 소비하게 될 수 있습니다. 그래서, 대규모 솔루션을 열 때 Visual Studio에서 사용하는 메모리의 최대 5-10 %까지 절약 된 문자열의 복사본 하나만 유지하도록 변경되었습니다.

Reducing project copies held onto by the project system

.NET 5 및 .NET Core 프로젝트 시스템의 중요한 디자인 측면 중 하나는 비동기입니다. 종종 프로젝트 시스템은 사용자 작업 (예 : 프로젝트에 대한 새 참조 추가)에 대한 응답으로 작업을 수행해야합니다. 작업을 완료하는 동안 Visual Studio를 차단하는 대신 프로젝트 시스템을 통해 사용자가 IDE에서 계속 작업하고 백그라운드에서 작업을 수행 할 수 있습니다.

 

사용자는 프로젝트 시스템이 백그라운드에서 이전 변경 사항을 처리하는 동안 프로젝트를 계속 변경할 수 있으므로 (예 : 또 다른 참조 추가) 프로젝트 시스템은 프로젝트 데이터의 스냅 샷을 저장하여 이후 작업이 이전 작업과 출돌하지 않도록 해야합니다. 따라서 프로젝트 시스템은 한 번에 여러개의 프로젝트 데이터 복사본을 메모리에 쉽게 저장할 수 있습니다. 프로젝트 시스템이 이러한 복사본 관리에 주의를 기울이지 않으면 필요 이상으로 오래 보관되거나 누출되어 영구히 보존될 수 있습니다. 한 번에 보관하는 사본 수를 줄이기 위해 적극적으로 노력했습니다.

Large solution load improvements

이 모든 작업을 통해 대규모 .NET 5 및 .NET Core 솔루션 작업 환경을 크게 최적화했습니다. 16.8을 기준으로 많은 테스트에서 리소스 문제가 발생하지 않는 솔루션의 크기가 2.5배 향상되었습니다. 또한 리소스 고갈로 인해 보고 된 충돌이 최대 25% 감소했습니다.

 

위에 나열된 개선 사항은 Visual Studio에서 대규모 솔루션 작업 환경을 개선하기 위해 수행하는 변경 사항의 시작에 불과합니다. 개별 솔루션 성능은 솔루션의 크기, 프로젝트 유형, 로드된 확장 등에 따라 여전히 다를 수 있으며 개선해야 할 영역이 여전히 있습니다. 모든 솔루션에 대한 솔루션 로드 환경을 지속적으로 개선 할 수 있도록 솔루션 로드 속도가 느려지거나 충돌하는 문제를 겪고있는 사용자는 vssolutionload@microsoft.com으로 문의하시기 바랍니다.

 

결과적으로 Microsoft에서도 대규모 솔루션으로 작업하는 것이 얼마나 어려운지 알고 있고 개선을 하기위해서 여러가지로 노력하고 있다는 것을 알 수 있는 것 같습니다. Visual Studio 옛날 버전을 사용하면서 메모리 문제로 인해서 어려워하시는 분들은 Visaul Studio 2019 최신 버전으로 업그레이드하는 것을 고려하심이 좋을 것 같다는 생각입니다.
반응형
댓글