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

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13697정성태7/26/2024386닷넷: 2283. C# - async 메서드에서의 lock/Monitor.Enter/Exit 잠금 처리파일 다운로드1
13696정성태7/26/2024297오류 유형: 920. dotnet publish - error NETSDK1047: Assets file '...\obj\project.assets.json' doesn't have a target for '...'
13695정성태7/25/2024328닷넷: 2282. C# - Lock / Wait 상태에서도 STA COM 메서드 호출 처리파일 다운로드1
13694정성태7/25/2024306닷넷: 2281. C# - ASP.NET Core Web App의 Request 용량 상한값 (Kestrel, IIS)
13693정성태7/24/2024459개발 환경 구성: 717. Visual Studio - C# 프로젝트에서 레지스트리에 등록하지 않은 COM 개체 참조 및 사용 방법파일 다운로드1
13692정성태7/24/2024459디버깅 기술: 199. Windbg - 리눅스에서 뜬 닷넷 응용 프로그램 덤프 파일에 포함된 DLL의 Export Directory 탐색
13691정성태7/23/2024522디버깅 기술: 198. Windbg - 스레드의 Win32 Message Queue 정보 조회
13690정성태7/23/2024533오류 유형: 919. Visual C++ 리눅스 프로젝트 - error : ‘u8’ was not declared in this scope
13689정성태7/22/2024527디버깅 기술: 197. Windbg - PE 포맷의 Export Directory 탐색
13688정성태7/21/2024662닷넷: 2280. C# - Lock / Wait 상태에서도 일부 Win32 메시지 처리파일 다운로드1
13687정성태7/19/2024675닷넷: 2279. C# - PostThreadMessage로 보낸 메시지를 Windows Forms에서 수신하는 방법파일 다운로드1
13686정성태7/19/2024626오류 유형: 918. Visual Studio - ATL Simple Object 추가 시 error C2065: 'IDR_...': undeclared identifier
13685정성태7/19/2024695스크립트: 66. Windows 디렉터리 경로를 WSL의 /mnt 포맷으로 구하는 방법 - 두 번째 이야기
13684정성태7/19/2024865닷넷: 2278. C# - 문자열 보간식 사례
13683정성태7/18/2024877오류 유형: 917. ClrMD - Linux 환경의 .NET 5 덤프 분석 시 hang 현상
13682정성태7/18/2024947닷넷: 2277. WPF - 스레드에 종속되는 DependencyObject파일 다운로드1
13681정성태7/17/20241014닷넷: 2276. C# 13 - (2) 메서드 그룹의 자연 타입 개선 (메서드 추론 개선)파일 다운로드1
13680정성태7/16/20241030닷넷: 2275. C# - Method Group, Natural Type, function_type파일 다운로드1
13679정성태7/16/20241040Linux: 75. Linux - C++ (getaddrinfo 등을 담고 있는) libnss 정적 링크
13678정성태7/15/2024898VS.NET IDE: 191. Visual Studio 2022 - .NET 5 프로젝트를 Docker Support로 실행했을 때 오류
13677정성태7/15/20241032오류 유형: 916. MSBuild - CheckEolTargetFramework (warning NETSDK1138)
13676정성태7/14/2024996Linux: 75. gdb에서 glibc의 함수에 Breakpoint 걸기
13675정성태7/13/2024988C/C++: 166. C/C++ - DLL에서 template 함수를 export하는 방법파일 다운로드1
13674정성태7/13/20241043오류 유형: 915. Unhandled Exception: Microsoft.Diagnostics.NETCore.Client.ServerNotAvailableException: Unable to connect to Process
13673정성태7/11/20241065닷넷: 2274. C# 13 - (1) 신규 이스케이프 시퀀스 '\e'파일 다운로드1
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...