C#, .NET 4.0, 64 비트를 사용하고 있습니다. 계산에 사용되는 5 억 개의 "데이터 포인트"를 메모리에 저장해야합니다. 이러한 구조체 또는 클래스 개체를 만들지 여부를 결정해야합니다. 구조체가 훨씬 빨라 보인다..NET 스택 메모리 한도
스택에 대한 메모리 제한이 있습니까? 그렇다면 어떻게 조정할 수 있습니까?
스택에 너무 많은 데이터를 저장하면 시스템의 전반적인 성능에 영향을 줍니까?
(그건 그렇고, .NET에서 단일 개체 크기 제한을 알고 있으므로 처리 중입니다. 데이터는 여러 컬렉션에 저장됩니다).
잘못된 질문을하고 있습니다. 스택 크기가 중요하다면, 뭔가 잘못하고있는 것입니다.
많은 데이터 포인트를 사용하는 경우이를 배열과 같은 컬렉션에 넣을 것입니다. 배열은 항상 힙에 할당됩니다. 구조체 배열은 개별 구조체를 포함하고 연속적인 메모리 블록을 형성합니다. (2GB가 넘는 경우 여러 배열이 필요합니다.)
참조 유형의 경우 배열에는 참조 만 포함되며 객체는 힙에 개별적으로 할당됩니다. 힙 할당에는 약 16 바이트의 오버 헤드가 있습니다. 배열에있는 참조는 또 다른 8을 차지합니다.
위도로 인해 캐시 지역이 더 나빠질 수 있으며 GC는 더 많은 작업을 수행하여 모든 참조를 크롤링해야합니다.
결론적으로 작은 데이터 포인트가 많은 경우이를 구조체로 만들고 배열에 넣어야합니다.
은 데이터 요소에 대한 클래스를 사용할 수 있습니다. 이 경우 메모리는 힙에 할당됩니다.
그러나 5 억 가지 데이터 포인트에 대해 이야기하고 있고 특히 앱에 대한 메모리 제한이보다 제한되어있는 .NET 환경에서 프로그래밍 중이므로 sqlite와 같은 일종의 내장 데이터베이스를 사용하는 것이 좋습니다. 예를 들면. 이 방법으로 모든 데이터 포인트가 동시에 메모리에 저장되는 것을 피할 수 있지만 계산에 필요한 데이터 포인트는 입니다. 이제입니다.
제 경험상 데이터베이스의 오버 헤드없이 대량의 데이터에 빠르게 액세스해야하는 경우가 일반적입니다. 그리고 이들을 모두 메모리에로드하면 참조 유형을 사용하기 위해 12GB의 오버 헤드가 발생합니다. 좋지 않아. – CodesInChaos
@CodeInChaos : 동의합니다. 사실, 제안 된 것처럼 메모리에 모든 것을로드하지는 않지만 데이터를 보관하기 위해 일부 'db'레이어를 사용하십시오. – Tigran
종종 성능상의 이유로 메모리에 모두 보관하려고합니다. 예를 들어, 수십 GB의 데이터가 큰 배열에 저장되는 물리 시뮬레이션과 관련하여 자주 작업합니다. – CodesInChaos
배열에 데이터를 저장하려고하며 배열은 항상 힙에 저장됩니다. 따라서 구조체 나 클래스를 사용하여 배열을 유지할지 여부는 중요하지 않습니다. 데이터 포인트 배열이 인접한 메모리 블록에 효율적으로 할당 될 수 있도록 데이터 포인트가 값 유형 (예 : 구조체)인지 확인하고 싶을 수 있습니다.
힙과 스택 할당 메모리 사이의 성능 차이는 짧은 시간 내에 할당 및 할당 해제 된 작은 개체에서 볼 수 있습니다. 설명하는 크기의 수명이 긴 오브젝트의 경우 스택 및 힙 할당 메모리간에 성능 차이가 없기를 기대합니다.
구조체가 힙에 할당되면 빠른 할당의 "이점"(질문 관점에서)이 손실됩니다. – Tigran
@Tigran 이러한 차이는 5 억 데이터 포인트에서 작업을 수행하면 측정 할 수 없습니다. –
@Tigran 배열의 일부가 아닌 경우. 구조체는 배열의 연속 메모리 블록으로 끝나고 클래스는 새로운 인스턴스 (관련된 16 바이트 오버 헤드가 있음)와 추가적인 방향을 가져옵니다. – CodesInChaos
힙과 스택을 혼동하지 않으시겠습니까? –
구조체가 클래스보다 "훨씬 더 빠릅니다"라고 가정/주장하는 근거는 무엇입니까? –
나는 OP가 스택 할당과 구조체 사이에 힘든 관계를 만들었다 고 추측한다. 이것은 잘못된 것이다. 이것들은 완전히 다른 주제이며 관련 될 수 있습니다. – Tigran