C#에서 바이트나 쇼트 대신 int를 사용해야 하는 이유

C#에서 바이트나 쇼트 대신 int를 사용해야 하는 이유

저는 이 문제와 관련하여 몇 가지 실마리를 찾았습니다.대부분의 사람들은 모바일 앱이 아닌 한 바이트나 스몰틴트가 데이터를 처리하더라도 보드 전체에서 int를 사용하는 것을 선호하는 것으로 보입니다.나는 왜 그런지 이해하지 않아요.C# 데이터 유형을 데이터 스토리지 솔루션과 동일한 데이터 유형으로 정의하는 것이 더 타당하지 않습니까?

내 전제:입력된 데이터 세트, Linq2SQL 클래스, POCO 등을 사용하는 경우 계층 간에 데이터 유형을 동기화하지 않으면 컴파일러 데이터 유형 변환 문제가 발생합니다.저는 시스템을 하는 것을 별로 좋아하지 않습니다.c# 코드에서 보드 전체에서 in을 사용하는 것이 더 쉽기 때문에 항상 변환합니다.데이터베이스에 대한 인터페이스를 깨끗하게 유지하기 위해 코드뿐만 아니라 데이터베이스의 데이터를 처리하는 데 필요한 최소한의 데이터 유형을 항상 사용했습니다.따라서 제 C# 코드의 75%가 int와 반대로 바이트 또는 쇼트를 사용하고 있을 것입니다. 왜냐하면 그것이 데이터베이스에 있기 때문입니다.

가능성:이것은 코드의 모든 것에 int를 사용하는 대부분의 사람들이 sql 스토리지 데이터 유형에도 int 데이터 유형을 사용하고 데이터베이스의 전체 크기에 대해 신경을 쓰지 않는다는 것을 의미합니까? 아니면 해당되는 경우 어디서나 system.convert를 코드로 수행합니까?

내가 신경쓰는 이유:저는 평생 혼자서 일해 왔으며 모범 사례와 표준 코딩 규칙을 숙지하고 싶습니다.

성능 측면에서는 거의 모든 경우에 int가 더 빠릅니다.CPU는 32비트 값으로 효율적으로 작동하도록 설계되었습니다.

짧은 값은 다루기가 복잡합니다.예를 들어, 단일 바이트를 읽으려면 CPU가 이를 포함하는 32비트 블록을 읽은 다음 상위 24비트를 마스킹해야 합니다.

바이트를 쓰려면 대상 32비트 블록을 읽고 하위 8비트를 원하는 바이트 값으로 덮어쓴 다음 전체 32비트 블록을 다시 써야 합니다.

물론 공간적으로는 더 작은 데이터 유형을 사용하여 몇 바이트를 절약할 수 있습니다.따라서 수백만 개의 행이 있는 테이블을 구축하는 경우에는 더 짧은 데이터 유형을 고려할 가치가 있습니다. (데이터베이스에서 더 작은 데이터 유형을 사용해야 하는 이유도 마찬가지일 수 있습니다.

그리고 정확성 측면에서, int는 쉽게 넘치지 않습니다.만약 여러분의 가치가 바이트 안에 들어맞을 것이라고 생각한다면, 그리고 미래의 어느 시점에서 코드에 대한 무해해해 보이는 변화가 더 큰 가치가 저장된다는 것을 의미한다면 어떨까요?

이러한 이유로 int가 모든 통합 데이터에 대한 기본 데이터 유형이어야 합니다.실제로 컴퓨터 바이트를 저장하려는 경우에만 바이트를 사용하십시오.16비트 정수 값을 실제로 지정하는 파일 형식이나 프로토콜 등을 다루는 경우에만 단축키를 사용하십시오.일반적으로 정수를 다루는 경우에는 정수를 int로 만듭니다.

6년밖에 늦었지만 다른 사람을 도울 수 있을지도 모릅니다.

다음은 제가 사용할 몇 가지 지침입니다.

• 미래에 데이터가 적합하지 않을 가능성이 있는 경우 큰 int 유형을 사용합니다.
• 변수가 struct/class 필드로 사용되는 경우 기본적으로 32비트 전체를 차지하도록 패딩되므로 byte/int16을 사용하면 메모리가 절약되지 않습니다.
• 변수가 (함수 내부처럼) 수명이 짧으면 데이터 유형이 작으면 큰 도움이 되지 않습니다.
• "byte" 또는 "char"는 때때로 데이터를 더 잘 설명할 수 있으며, 실수로 더 큰 값이 할당되지 않도록 컴파일 시간 검사를 수행할 수 있습니다. 예를 들어 바이트를 사용하여 날짜(1-31)를 저장하고 1000을 할당하려고 하면 오류가 발생합니다.
• 변수가 대략 100개 이상의 배열에서 사용되는 경우, 의미가 있는 한 더 작은 데이터 유형을 사용할 것입니다.
• 바이트 및 int16 배열은 int(기본)만큼 스레드 안전하지 않습니다.

아무도 꺼내지 않은 한 가지 주제는 제한된 CPU 캐시입니다.CPU가 더 빠른 L1/L2/L3 캐시에 더 많은 프로그램을 넣을 수 있기 때문에 작은 프로그램이 큰 프로그램보다 더 빨리 실행됩니다.

int 유형을 사용하면 CPU 명령 수가 줄어들 수 있지만 CPU 캐시에 맞지 않는 데이터 메모리 비율이 높아집니다.명령어는 실행 비용이 저렴합니다.최신 CPU 코어는 클럭 주기당 3-7개의 명령을 실행할 수 있지만, RAM까지 사용해야 하기 때문에 한 번의 캐시 누락으로 인해 1000-2000개의 클럭 주기가 소요될 수 있습니다.

메모리가 보존되면 캐시에서 압축되지 않기 때문에 나머지 애플리케이션의 성능도 향상됩니다.

바이트 배열과 int 배열을 모두 사용하여 랜덤 데이터를 랜덤 순서로 액세스하여 빠른 합계 테스트를 수행했습니다.

const int SIZE = 10000000, LOOPS = 80000;
byte[] array = Enumerable.Repeat(0, SIZE).Select(i => (byte)r.Next(10)).ToArray();
int[] visitOrder = Enumerable.Repeat(0, LOOPS).Select(i => r.Next(SIZE)).ToArray();

System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
sw.Start();
int sum = 0;
foreach (int v in visitOrder)
    sum += array[v];
sw.Stop();

시간(ticks) 결과는 다음과 같습니다. (x86, 릴리스 모드, 디버거 없음, .NET 4.5, I7-3930k) (작은 것이 좋습니다.)

________________ Array Size __________________
       10  100   1K   10K  100K    1M   10M 
byte: 549  559  552   552   568   632  3041  
int : 549  566  552   562   590  1803  4206

• CPU의 바이트를 사용하여 무작위로 1M 항목에 액세스하면 성능이 285% 향상되었습니다!
• 10,000 미만의 것은 거의 눈에 띄지 않았습니다.
• int는 이 기본 합계 테스트에서 바이트보다 결코 빠르지 않았습니다.
• 이러한 값은 캐시 크기가 다른 CPU에 따라 달라집니다.

마지막으로 마이크로소프트의 전문가들이 무엇을 하는지 알아보기 위해 가끔 오픈 소스 닷넷 프레임워크를 봅니다..NET 프레임워크는 바이트/int16을 사용하지 않습니다.저는 실제로 아무것도 찾을 수 없었습니다.

몇 십억 개의 행을 처리해야 스토리지 용량 측면에서 큰 차이가 발생할 수 십억 개의 행을 처리해야 합니다.세 개의 열이 있고 바이트 등가 데이터베이스 유형을 사용하는 대신 int 등가 데이터베이스 유형을 사용한다고 가정합니다.

그러면 행당 3개(열) x 3개(바이트 추가) 또는 행당 9개(바이트 추가)가 제공됩니다.

즉, "수백만 행"(예: 3백만 행)의 경우 27메가바이트의 디스크 공간을 추가로 사용하게 됩니다.다행히 우리는 더 이상 1970년대에 살고 있지 않기 때문에, 당신은 이것에 대해 걱정할 필요가 없습니다:)

위에서 언급한 바와 같이 마이크로 최적화를 중단하십시오. 매우 매우 큰 데이터셋을 처리하지 않는 한, 서로 다른 정수형 숫자 유형으로 변환하거나 변환할 때의 성능은 대역폭/디스크 공간 비용보다 훨씬 더 큰 타격을 입을 것입니다.

대부분은 '아니오'입니다.

수억 개의 행을 처리하게 될 것이라는 사실을 미리 알고 있지 않는 한, 이는 미세 최적화입니다.

도메인 모델에 가장 적합한 작업을 수행합니다.나중에 성능 문제가 있는 경우 벤치마크 및 프로파일을 사용하여 문제가 발생한 위치를 파악합니다.

존 그랜트와 다른 사람들을 믿지 않았던 것은 아니지만, 저는 우리의 "백만 줄 테이블"을 직접 봐야 했습니다.이 테이블은 1,018,000개입니다.11개의 작은 int 열과 6개의 작은 int 열을 int로 변환했는데, 이미 5개의 int & 3개의 작은 날짜가 있었습니다.4개의 다른 인덱스는 다양한 데이터 유형의 조합을 사용했지만, 새 인덱스는 이제 모두 int 열을 사용합니다.

인덱스 없이 기본 테이블 디스크 사용량을 계산하는 데 40MB만 소요됩니다.인덱스를 다시 추가했을 때 전체 변경 내용은 30MB밖에 차이가 나지 않았습니다.그래서 인덱스 사이즈가 더 클 것 같아서 깜짝 놀랐습니다.

그래서 30MB는 모든 다른 데이터 유형을 사용하는 번거로움을 감수할 가치가 있습니다, 말도 안 돼요!저는 INTland에 갑니다. 이 잠재력 있는 프로그래머를 더 이상 정수 변환을 하지 않는 정직하고 행복한 삶으로 되돌려준 모든 사람들에게 감사드립니다.이피!

.NET 런타임은 Int32에 최적화되어 있습니다..NET Integer 대 Int16에서 이전 논의 내용을 살펴보시겠습니까?

모든 곳에서 int를 사용하는 경우 주조나 변환이 필요하지 않습니다.이는 여러 정수 크기를 사용하여 절약할 수 있는 메모리보다 훨씬 큰 비용입니다.

그것은 단지 삶을 더 단순하게 만듭니다.

언급URL : https://stackoverflow.com/questions/1097467/why-should-i-use-int-instead-of-a-byte-or-short-in-c-sharp