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)
13560정성태2/19/20242056디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20242937오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20242161닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241913Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241956Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20242112닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241856VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241938닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241887닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242084닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242198Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242500개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20242330개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242084개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241941Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20241858닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20241882오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20241880Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20241912오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20241954VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20242075Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242364개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20242415닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20242500닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20242587닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/20242431닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...