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/
정성태

... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12211정성태4/27/202019280개발 환경 구성: 486. WSL에서 Makefile로 공개된 리눅스 환경의 C/C++ 소스 코드 빌드
12210정성태4/20/202020735.NET Framework: 903. .NET Framework의 Strong-named 어셈블리 바인딩 (1) - app.config을 이용한 바인딩 리디렉션 [1]파일 다운로드1
12209정성태4/13/202017427오류 유형: 614. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우 (2)
12208정성태4/12/202016003Linux: 29. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우
12207정성태4/2/202015857스크립트: 19. Windows PowerShell의 NonInteractive 모드
12206정성태4/2/202018451오류 유형: 613. 파일 잠금이 바로 안 풀린다면? - The process cannot access the file '...' because it is being used by another process.
12205정성태4/2/202015116스크립트: 18. Powershell에서는 cmd.exe의 명령어를 지원하진 않습니다.
12204정성태4/1/202015136스크립트: 17. Powershell 명령어에 ';' (semi-colon) 문자가 포함된 경우
12203정성태3/18/202017969오류 유형: 612. warning: 'C:\ProgramData/Git/config' has a dubious owner: '...'.
12202정성태3/18/202021216개발 환경 구성: 486. .NET Framework 프로젝트를 위한 GitLab CI/CD Runner 구성
12201정성태3/18/202018460오류 유형: 611. git-credential-manager.exe: Using credentials for username "Personal Access Token". [1]
12200정성태3/18/202018550VS.NET IDE: 145. NuGet + Github 라이브러리 디버깅 관련 옵션 3가지 - "Enable Just My Code" / "Enable Source Link support" / "Suppress JIT optimization on module load (Managed only)"
12199정성태3/17/202016183오류 유형: 610. C# - CodeDomProvider 사용 시 Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '...\f2_6uod0.tmp'.
12198정성태3/17/202019543오류 유형: 609. SQL 서버 접속 시 "Cannot open user default database. Login failed."
12197정성태3/17/202018850VS.NET IDE: 144. .NET Core 콘솔 응용 프로그램을 배포(publish) 시 docker image 자동 생성 - 두 번째 이야기 [1]
12196정성태3/17/202015975오류 유형: 608. The ServicedComponent being invoked is not correctly configured (Use regsvcs to re-register).
12195정성태3/16/202018285.NET Framework: 902. C# - 프로세스의 모든 핸들을 열람 - 세 번째 이야기
12194정성태3/16/202021007오류 유형: 607. PostgreSQL - Npgsql.NpgsqlException: sorry, too many clients already
12193정성태3/16/202017958개발 환경 구성: 485. docker - SAP Adaptive Server Enterprise 컨테이너 실행 [1]
12192정성태3/14/202019999개발 환경 구성: 484. docker - Sybase Anywhere 16 컨테이너 실행
12191정성태3/14/202021073개발 환경 구성: 483. docker - OracleXE 컨테이너 실행 [1]
12190정성태3/14/202015657오류 유형: 606. Docker Desktop 업그레이드 시 "The process cannot access the file 'C:\Program Files\Docker\Docker\resources\dockerd.exe' because it is being used by another process."
12189정성태3/13/202021255개발 환경 구성: 482. Facebook OAuth 처리 시 상태 정보 전달 방법과 "유효한 OAuth 리디렉션 URI" 설정 규칙
12188정성태3/13/202026045Windows: 169. 부팅 시점에 실행되는 chkdsk 결과를 확인하는 방법
12187정성태3/12/202015634오류 유형: 605. NtpClient was unable to set a manual peer to use as a time source because of duplicate error on '...'.
12186정성태3/12/202017416오류 유형: 604. The SysVol Permissions for one or more GPOs on this domain controller and not in sync with the permissions for the GPOs on the Baseline domain controller.
... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...