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)
13256정성태2/10/20235188개발 환경 구성: 665. WSL 2의 네트워크 통신 방법 - 두 번째 이야기
13255정성태2/10/20234521오류 유형: 845. gihub - windows2022 이미지에서 .NET Framework 4.5.2 미만의 프로젝트에 대한 빌드 오류
13254정성태2/10/20234407Windows: 223. (WMI 쿼리를 위한) PowerShell 문자열 escape 처리
13253정성태2/9/20235182Windows: 222. C# - 다른 윈도우 프로그램이 실행되었음을 인식하는 방법파일 다운로드1
13252정성태2/9/20234004오류 유형: 844. ssh로 명령어 수행 시 멈춤 현상
13251정성태2/8/20234458스크립트: 44. 파이썬의 3가지 스레드 ID
13250정성태2/8/20236277오류 유형: 843. System.InvalidOperationException - Unable to configure HTTPS endpoint
13249정성태2/7/20235121오류 유형: 842. 리눅스 - You must wait longer to change your password
13248정성태2/7/20234170오류 유형: 841. 리눅스 - [사용자 계정] is not in the sudoers file. This incident will be reported.
13247정성태2/7/20235071VS.NET IDE: 180. Visual Studio - 닷넷 소스 코드 디버깅 중 "Decompile source code"가 동작하는 않는 문제
13246정성태2/6/20234199개발 환경 구성: 664. Hyper-V에 설치한 리눅스 VM의 VHD 크기 늘리는 방법 - 두 번째 이야기
13245정성태2/6/20234771.NET Framework: 2093. C# - PEM 파일을 이용한 RSA 개인키/공개키 설정 방법파일 다운로드1
13244정성태2/5/20234127VS.NET IDE: 179. Visual Studio - External Tools에 Shell 내장 명령어 등록
13243정성태2/5/20234977디버깅 기술: 190. windbg - Win32 API 호출 시점에 BP 거는 방법 [1]
13242정성태2/4/20234420디버깅 기술: 189. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.UnauthorizedAccessException
13241정성태2/3/20233920디버깅 기술: 188. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.IO.FileNotFoundException
13240정성태2/1/20234076디버깅 기술: 187. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.Web.HttpException
13239정성태2/1/20233738디버깅 기술: 186. C# - CacheDependency의 숨겨진 예외 - System.Web.HttpException
13238정성태1/31/20235821.NET Framework: 2092. IIS 웹 사이트를 TLS 1.2 또는 TLS 1.3 프로토콜로만 운영하는 방법
13237정성태1/30/20235480.NET Framework: 2091. C# - 웹 사이트가 어떤 버전의 TLS/SSL을 지원하는지 확인하는 방법
13236정성태1/29/20235090개발 환경 구성: 663. openssl을 이용해 인트라넷 IIS 사이트의 SSL 인증서 생성
13235정성태1/29/20234647개발 환경 구성: 662. openssl - 윈도우 환경의 명령행에서 SAN 적용하는 방법
13234정성태1/28/20235729개발 환경 구성: 661. dnSpy를 이용해 소스 코드가 없는 .NET 어셈블리의 코드를 변경하는 방법 [1]
13233정성태1/28/20237057오류 유형: 840. C# - WebClient로 https 호출 시 "The request was aborted: Could not create SSL/TLS secure channel" 예외 발생
13232정성태1/27/20234809스크립트: 43. uwsgi의 --processes와 --threads 옵션
13231정성태1/27/20233738오류 유형: 839. python - TypeError: '...' object is not callable
1  2  3  4  5  6  7  8  9  10  11  12  13  14  [15]  ...