Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)

System.IO.MemoryStream, ArraySegment<T> 의 효율적인 사용법

MemroyStream으로부터 바이트 스트림을 반환받을 수 있는 방법이 2가지입니다. 하나는 GetBuffer, 또 다른 하나는 ToArray인데요.

다음의 예제를 보면 대번에 그 차이점을 알 수 있습니다.

using System;
using System.Text;
using System.IO;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            MemoryStream ms = new MemoryStream();

            byte [] buf = Encoding.UTF8.GetBytes("hello");
            ms.Write(buf, 0, buf.Length);

            byte[] getBuffer = ms.GetBuffer();
            Console.WriteLine("GetBuffer.Length: " + getBuffer.Length); // 256

            byte[] toArray = ms.ToArray();
            Console.WriteLine("ToArray.Length: " + toArray.Length); // 5
        }
    }
}

보시는 바와 같이 GetBuffer는 블록으로 잡혀진 바이트 배열을 통째로 반환하는 반면 ToArray는 정확히 사용된 바이트 만큼의 배열을 반환합니다.

일단, 표면상으로 보면 ToArray를 사용하는 것이 좋습니다.




문제는, 데이터가 커지면서 발생합니다. 왜냐하면 2개의 메소드가 내부 구현방식이 다르기 때문입니다.

public virtual byte[] GetBuffer() // 내부에 이미 할당된 바이트 배열 변수를 그대로 반환
{
    if (!this._exposable)
    {
        throw new UnauthorizedAccessException(...);
    }
    return this._buffer;
}

public virtual byte[] ToArray() // 새롭게 배열을 생성하고 내용을 복사해서 반환
{
    byte[] dst = new byte[this._length - this._origin];
    Buffer.InternalBlockCopy(this._buffer, this._origin, dst, 0, this._length - this._origin);
    return dst;
}

따라서, GC(Garbage Collector)입장에서는 ToArray가 부담스러운 메소드에 속합니다. 물론, 크기가 작으면 상관없지만 대개 바이트 스트림을 다루는 경우는 고용량 데이터를 다루는 경우가 많기 때문에 메모리 할당이 순간적으로 2배가 되는 것은 그다지 바람직하지 않습니다.

어디... 실제 사례를 통해 알아볼까요? ^^ 다음은 최근에 본 어느 업체의 GZIP 압축 코드입니다.

static ArraySegment<byte> CompressBuffer(ArraySegment<byte> buffer, BufferManager bufferManager, int messageOffset)
{
    MemoryStream stream = new MemoryStream();
    stream.Write(buffer.Array, 0, messageOffset);
    using (GZipStream stream2 = new GZipStream(stream, CompressionMode.Compress, true))
    {
        stream2.Write(buffer.Array, messageOffset, buffer.Count);
    }
    byte[] sourceArray = stream.ToArray();
    byte[] destinationArray = bufferManager.TakeBuffer(sourceArray.Length);
    Array.Copy(sourceArray, 0, destinationArray, 0, sourceArray.Length);
    bufferManager.ReturnBuffer(buffer.Array);
    return new ArraySegment<byte>(destinationArray, messageOffset, sourceArray.Length);
}

위의 코드에서는 압축된 바이트 배열을 ToArray 로 받았는데, 따라서 50MB를 압축해서 25MB를 얻었으면 순간적으로 다시 25MB가 힙에 할당되는 것입니다. (사실, 이런 코드도 데스크톱 응용 프로그램에 쓰이면 별로 문제가 안 될 수 있는데, 위의 코드는 웹에서 사용된 것입니다.) 따라서, 이런 경우 GetBuffer를 이용해 다음과 같이 변환하는 것이 더 메모리 효율적인 코드가 나옵니다.

byte[] sourceArray = stream.GetBuffer();
int sourceLength = stream.Length;

byte[] destinationArray = bufferManager.TakeBuffer(sourceLength);
Array.Copy(sourceArray, 0, destinationArray, 0, sourceLength);

GetBuffer를 이용해 MemoryStream 내부 버퍼를 이용하고, 실제 데이터 크기를 반환하는 Length 속성을 조합하면 ToArray를 사용했을 때의 부작용을 해결할 수 있습니다.

물론, GetBuffer에는 한 가지 치명적인 단점이 존재합니다. MemoryStream.Dispose를 호출한 이후에는 원본 바이트 배열이 해제되기 때문에 이후의 조작에서 예외가 발생합니다. 따라서, Stream이 닫히기 전에 임시로 데이터를 접근해야 할 때에만 GetBuffer를 사용하는 것이 좋습니다. 혹은 그런 부작용을 없애고 싶다면 MemoryStream은 명시적으로 닫지 말고 GC에 맡기는 방법이 있습니다.




문제는, GetBuffer로 반환받은 배열 변수를 이용하는 경우 에러를 유발할 수 있는 여지가 많다는 점입니다. MemoryStream.Length 속성을 반드시 사용해야 하는데도 불구하고 무심코 바이트 배열의 Length를 사용할 수 있습니다.

ArraySegment<T>는 이런 문제를 자연스럽게 해결해 줍니다. 이름이 좀 낯설어서 그럴 뿐, ArraySegment는 원본 데이터에 대한 뷰(View)를 구현해주는 단순한 구조의 타입에 불과합니다. 예를 들어서, MemoryStream의 데이터를 로그에 남기는 메소드를 만든다고 가정해 보겠습니다.

byte[] getBuffer = ms.GetBuffer();
LogBytes(getBuffer, ms.Length);

private static void LogBytes(byte[] buffer, long length)
{
    for (long idx = 0; idx < length; idx++)
    {
        Console.Write(buffer[idx].ToString("x") + ", ");
    }
    Console.WriteLine();
}

언제나 2개의 변수를 전달해야 하는 불편함을, ArraySegment를 이용해 다음과 같이 해결할 수 있습니다. (물론, 그냥 MemoryStream을 넘겨도 되겠지만.)

byte[] getBuffer = ms.GetBuffer();

ArraySegment<byte> segment = new ArraySegment<byte>(getBuffer, 0, (int)ms.Length);
LogBytes(segment);

private static void LogBytes(ArraySegment<byte> segment)
{
    for (long idx = 0; idx < segment.Count; idx++)
    {
        Console.Write(segment.Array[idx].ToString("x") + ", ");
    }

    Console.WriteLine();
}

알고 보면 ArraySegment도 별거 아니죠? ^^

자, 그럼 기준을 간단하게 정리해 보겠습니다. 소규모 데이터를 다룰 때면 편리하게 ToArray를 다뤄도 좋습니다. 반면, 대규모 데이터를 다뤄야 할 때면 반드시 GetBuffer에 대한 사용을 고려해야 합니다. 이도 저도 귀찮을 때는 무조건 GetBuffer + ArraySegment만을 전체적으로 사용하는 것이 좋겠고!




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 1/4/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2024-02-02 09시19분
How To Use ArraySegment in C#
; https://code-maze.com/csharp-arraysegment/
정성태

... 76  77  78  79  80  81  82  83  84  [85]  86  87  88  89  90  ...
NoWriterDateCnt.TitleFile(s)
11844정성태3/14/201924526개발 환경 구성: 434. Visual Studio 2019 - 리눅스 프로젝트를 이용한 공유/실행(so/out) 프로그램 개발 환경 설정 [1]파일 다운로드1
11843정성태3/14/201919348기타: 75. MSDN 웹 사이트를 기본으로 영문 페이지로 열고 싶다면?
11842정성태3/13/201917209개발 환경 구성: 433. 마이크로소프트의 CoreCLR 프로파일러 예제를 Visual Studio CMake로 빌드하는 방법 [1]파일 다운로드1
11841정성태3/13/201917666VS.NET IDE: 132. Visual Studio 2019 - CMake의 컴파일러를 기본 g++에서 clang++로 변경
11840정성태3/13/201919733오류 유형: 526. 윈도우 10 Ubuntu App 환경에서는 USB 외장 하드 접근 불가
11839정성태3/12/201923748디버깅 기술: 124. .NET Core 웹 앱을 호스팅하는 Azure App Services의 프로세스 메모리 덤프 및 windbg 분석 개요 [3]
11838정성태3/7/201927494.NET Framework: 811. (번역글) .NET Internals Cookbook Part 1 - Exceptions, filters and corrupted processes [1]파일 다운로드1
11837정성태3/6/201941167기타: 74. 도서: 시작하세요! C# 7.3 프로그래밍 [10]
11836정성태3/5/201924826오류 유형: 525. Visual Studio 2019 Preview 4/RC - C# 8.0 Missing compiler required member 'System.Range..ctor' [1]
11835정성태3/5/201922971.NET Framework: 810. C# 8.0의 Index/Range 연산자를 .NET Framework에서 사용하는 방법 및 비동기 스트림의 컴파일 방법 [3]파일 다운로드1
11834정성태3/4/201921647개발 환경 구성: 432. Visual Studio 없이 최신 C# (8.0) 컴파일러를 사용하는 방법
11833정성태3/4/201922714개발 환경 구성: 431. Visual Studio 2019 - CMake를 이용한 공유/실행(so/out) 리눅스 프로젝트 설정파일 다운로드1
11832정성태3/4/201917724오류 유형: 524. Visual Studio CMake - rsync: connection unexpectedly closed
11831정성태3/4/201918506오류 유형: 523. Visual Studio 2019 - 새 창으로 뜬 윈도우를 닫을 때 비정상 종료
11830정성태2/26/201917749오류 유형: 522. 이벤트 로그 - Error opening event log file State. Log will not be processed. Return code from OpenEventLog is 87.
11829정성태2/26/201919044개발 환경 구성: 430. 마이크로소프트의 CoreCLR 프로파일러 예제 빌드 방법 - 리눅스 환경 [1]
11828정성태2/26/201927456개발 환경 구성: 429. Component Services 관리자의 RuntimeBroker 설정이 2개 있는 경우 [8]
11827정성태2/26/201919921오류 유형: 521. Visual Studio - Could not start the 'rsync' command on the remote host, please install it using your system package manager.
11826정성태2/26/201920456오류 유형: 520. 우분투에 .NET Core SDK 설치 시 패키지 의존성 오류
11825정성태2/25/201926123개발 환경 구성: 428. Visual Studio 2019 - CMake를 이용한 리눅스 빌드 환경 설정 [1]
11824정성태2/25/201920403오류 유형: 519. The SNMP Service encountered an error while accessing the registry key SYSTEM\CurrentControlSet\Services\SNMP\Parameters\TrapConfiguration. [1]
11823정성태2/21/201921381오류 유형: 518. IIS 관리 콘솔이 뜨지 않는 문제
11822정성태2/20/201920541오류 유형: 517. docker에 설치한 MongoDB 서버로 연결이 안 되는 경우
11821정성태2/20/201921303오류 유형: 516. Visual Studio 2019 - This extension uses deprecated APIs and is at risk of not functioning in a future VS update. [1]
11820정성태2/20/201924442오류 유형: 515. 윈도우 10 1809 업데이트 후 "User Profiles Service" 1534 경고 발생
11819정성태2/20/201923496Windows: 158. 컴퓨터와 사용자의 SID(security identifier) 확인 방법
... 76  77  78  79  80  81  82  83  84  [85]  86  87  88  89  90  ...