Microsoft MVP성태의 닷넷 이야기
.NET Framework: 374. C#과 비교한 C++ STL vector 성능 [링크 복사], [링크+제목 복사],
조회: 31247
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

C#과 비교한 C++ STL vector 성능

테스트를 위해 C#으로 다음과 같은 식의 예제를 만들 일이 있었습니다.

class Program
{
    static void Main(string[] args)
    {
        string body = "...[10만 개의 0~9 숫자로 이뤄진 문자열]...";

        int loopCount = 10000;
        byte [] bodyContents = Encoding.UTF8.GetBytes(body);

        for (int i = 0; i < 100; i++)
        {
            MemoryStream ms = new MemoryStream();
            ms.Write(bodyContents, 0, bodyContents.Length);
            ms.Flush();
        }
    }
}

보시는 바와 같이 간단합니다. 그런데, 이 예제를 Visual C++로도 만들어 보았는데,

#include "stdafx.h"

#include <string>
#include <vector>

using namespace std;

int _tmain(int argc, _TCHAR* argv[])
{
    vector<unsigned char> bodyBuf;

    // bodyBuf = ...[10만 개의 0~9 숫자로 이뤄진 문자열]...

    for (int i = 0; i < 100; i ++)
    {
        vector<unsigned char> dataBuf;
        dataBuf.insert(dataBuf.end(), body.begin(), body.end());
    }

    return 0;
}

차이점이라면 C#의 MemoryStream을 단순히 vector<unsigned char>로 치환한 정도입니다. 이를 각각 x64, Release 빌드하고 성능 비교를 해보면 다음과 같습니다.

C# MemoryStream: 4밀리초
C++ vector.insert: 15밀리초

오히려 C#이 빠르죠. ^^ 물론, 약간 불공정한 면이 있습니다. MemoryStream의 Write는 아마도 내부적으로 memcpy를 사용할테니 공정하게 테스트를 하려면 C#에서도 List<byte>와 같은 자료 구조를 사용해야 합니다.

Stopwatch st = new Stopwatch();

st.Start();

for (int i = 0; i < 100; i++)
{
    List<byte> list = new List<byte>();

    for (int j = 0; j < bodyContents.Length; j++)
    {
        list.Add(bodyContents[j]);
    }
    
    //MemoryStream ms = new MemoryStream();
    //ms.Write(bodyContents, 0, bodyContents.Length);
    //ms.Flush();
}

st.Stop();

Console.WriteLine(st.ElapsedMilliseconds); // 수행 시간: 46밀리초

예상대로 C++의 vector보다 느립니다. 반대로 MemoryStream과 같은 속도로 C++ 속도를 개선하는 것은 memcpy를 쓰면 됩니다.

for (int i = 0; i < 100; i ++)
{
    vector<unsigned char> dataBuf;

    dataBuf.reserve(bodyBuf.size());
    memcpy(dataBuf.data(), bodyBuf.data(), bodyBuf.size());
}

// 수행시간: 6밀리초

결과는 다음과 같이 정리할 수 있는데, 다소 의외인 점이라면 C++에서 memcpy를 했는데도 C#의 MemoryStream과 비교하면 근소하게 느렸다는 것입니다.

=== 64비트 Release ===
C# MemoryStream: 4밀리초
C# List: 46밀리초

C++ memcpy: 6밀리초
C++ vector: 15밀리초




테스트할 가치는 크게 없지만, 혹시나 싶어 Debug 빌드로도 성능 측정을 해보았습니다.

=== 64비트 Debug ===
C# MemoryStream: 5밀리초
C# List: 112밀리초

C++ memcpy: 1 밀리초
C++ vector: 2760밀리초

재미있는 점은 C++ memcpy 결과가 Release 빌드보다 더욱 빨랐다는 것입니다. ^^( 이 결과가 너무 이상해서 몇 번을 해봤는데 결과가 같았습니다. 신기하군요. ^^) C#의 MemoryStream은 Debug/Release에 별로 영향을 받지 않는데, 내부적으로 호출되는 메모리 복사 코드는 결국 P/Invoke를 통한 C/C++ 코드의 실행이기 때문입니다.

32비트로 빌드한 것도 약간 흥미롭습니다.

=== 32비트 Release ===
C# MemoryStream: 4밀리초
C# List: 52밀리초

C++ memcpy: 16밀리초
C++ vector: 27밀리초

=== 32비트 Debug ===
C# MemoryStream: 5밀리초
C# List: 95밀리초

C++ memcpy: 12밀리초
C++ vector: 7879밀리초

32비트 Debug로는 C++ vector는 몹쓸 성능을 보입니다. ^^ 또한, 전체적인 성능은 x64가 x86보다 다소 낫다는 것도 알 수 있고!

그나저나, C++이 어느새 많이 발전했습니다. 이제는 C#과 같은 언어로 만든 프로그램을 C++로 포팅하는데 거의 유사하게 코드가 작성되는 경험을 했습니다. 특히 ^^ std::thread가 나온 것이 너무 반갑습니다. 그러면서 느낀 점이 있다면, ^^ 옛말(?)에 잘못 짠 어셈블리는 C++보다 느리다고 하더니... 이제는 대충 짠 C++은 C#보다 느리다는 말이 나올 듯합니다.

테스트 한 소스 코드는 첨부해 두었습니다. Visual Studio 2012에서 닷넷은 4.0으로, C++은 Platform Toolset을 v110으로 맞춘 기본 상태입니다.




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







[최초 등록일: ]
[최종 수정일: 7/10/2021]

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

비밀번호

댓글 작성자
 



2014-05-12 02시24분
[나] vector 를 가지고 삽입 연산 실험을 한게 이해할 수 없군요.
[guest]
2015-04-02 04시12분
[지나가나] vector를 사용할때 성능을 위해 이니셜크기를 설정하고 push_back()으로 값을 넣죠..
인접한 위치에 데이터를 저장하는 vector에 메모리 이동을 최소화 하기 위해 insert는 거의 사용하지 않는데..
왜 insert를 이용해 테스트를 하셨는지 모르겠네요..
[guest]
2015-04-02 01시37분
^^;;; vector의 insert 호출에 의외로 민감한 반응을 보이시는 두 분이군요. 우선, 그 부분에 대해서는 '거의 사용하지도 않는 함수'를 vector에 집어 넣은 STL 팀에다 직접 '뭐하러 넣었냐'고 물어봐 주시고, 그 응답을 여기다 덧글로 달아주시면 정말 감사드리겠습니다.

혹시나 기초가 없으셔서 그런지 몰라 굳이 설명을 드리면, vector는 그 크기가 정적이 아닌 동적이라는 장점을 가진 자료 구조입니다. 그런 특징을 가진 vector에 '삽입 연산을 한 것에 대해 이해할 수가 없다'는 말을 오히려 제가 이해할 수가 없군요. 삽입 연산을 안 할거면, 뭐하러 vector를 만드나요? 그냥 고정 배열을 쓰면 되지요. 아니면 모든 요소를 연결 리스트로 이어주도록 만들거나 해야겠지요? (그렇게 하실 겁니까?)

@지나가나 님은 본문을 잘 읽어보신 것인지 의문이군요. 본문에 보면, vector에 vector를 append하는 코드인데 아쉽게도 push_back 함수는 vector를 인자로 받지 못합니다. 기왕이면 다음의 글에 가서, 왜 vector에 push_back을 안 쓰고 insert를 썼냐고 반대 의견을 내어 별표를 획득하고 오시면 그때는 저도 "지나가나" 님의 답변을 신중하게 고려해 보겠습니다.

C++: Appending a vector to a vector
; http://stackoverflow.com/questions/2551775/c-appending-a-vector-to-a-vector

참고로, 본문을 다시 읽어보시면, 제 코드는 vector의 중간에 insert를 한 코드는 없습니다. 따라서, (버퍼가 꽉 차 새롭게 할당받은 버퍼로) 메모리 이동이 발생한다는 점에서는 push_back이든 insert든 모두 동일하게 발생합니다. 또한 이니셜 크기를 설정하지 않은 것에 대한 언급을 왜 굳이 하셨는지 이해가 안되는 군요. 본문에 보면 reserve 함수 호출로 초기 크기를 설정한다는 것도 설명해 두었습니다. 설령 이니셜 크기를 설정하지 않은 것으로 본문의 이야기를 끝냈다고 해도 그 패널티는 MemoryStream과 List의 코드에도 마찬가지로 초기 크기는 지정하지 않았으므로 크게 논란이 될 여지는 없을 듯합니다.
정성태
2021-12-15 08시11분
[행인] 시간이 오래지난 글이라 의미는 없지만, 추후 누군가가 잘못된 정보를 보게 될 확률이 있어서 한 말씀 드리자면
애초에 reserve로 크기가 정해진 vector임에도 할당을 해놓지 않았고(메모리 스트림은 크기를 할당한 상태죠?)
벡터속도는 사실 최근의 C++에서는 memcpy 속도와 다르지 않아서 결국 메모리 대역폭에 의해 결정됩니다.
의미없는 실험이라고 할 수 있겠네요.
C++의 stl의 인터페이스는 표준이 있지만, 내부 구현은 표준이 없어서 C++을 싸잡아서 느리다 라고 말할 수 없습니다. 컴파일러별로 다를거거든요.
차라리 C#과 비교하려면 map과 같은 rb트리 속도를 재는건 의미가 있을 수 있죠
[guest]
2021-12-16 12시11분
[dimohy] @행인 님의 글이 우려가 되어 댓글을 달아봅니다. 어떤 점이 잘못된 정보인지 어떤 맥락으로 그렇게 이해했는지 모르겠습니다. 예를 들어 본 글에서 reserve를 쓴 이유는 되려 반대로 공평하게 평가하기 위해 사용된 것입니다. (이유는 본 글에도 있습니다)

1. reserve로 크기가 정해진 vector임에도 할당을 해놓지 않았고 -> reserve가 메모리 할당을 하는 기능입니다. resize와 다른점은 단지 size에 반영하지 않을 뿐입니다.
2. 메모리 스트림은 크기를 할당한 상태죠? -> 위의 MemoryStream를 생성한 코드에서 capacity이 없지 않나요? 이말은 무슨 말이죠?

이후의 @행인 님의 주장하는 맥락은 결국에는 Vector 속도가 memcpy 속도와 다르지 않다고 하는데 그 근거가 어디에 있죠? Vector의 동작 알고리즘은 알고 말씀하시는지 모르겠습니다. C#의 MemoryStream 또는 List의 동작이나 C++의 Vector의 동작은 용량이 변경될 수 있는 대상을 다루기 위해 존재합니다. 그렇기 때문에 내부적으로 사용하는 메모리 량은 n*2의 형태로 증가하게 되는데, 필연적으로 용량이 증가해 capacity를 넘게 되면 새로운 메모리를 할당하고 기존 데이터를 복사 해야만 합니다. (C#이나 C++이나 다를게 없다는 것이죠) 차이점은 C#은 메모리 관리 언어기 때문에 추가적인 비용이 발생한다는 점입니다.

본 내용은 C#의 MemoryStream의 성능이 생각보다 뛰어났다는 점 (하지만 STL Vector의 비교대상은 MemoryStream이 아니죠 List입니다.)
C#의 List는 메모리 관리 언어의 특성상 추가적인 비용이 발생했다는 점을 잘 비교한 올바른 글입니다.
[guest]
2021-12-16 12시15분
@행인 이 글의 주제는 C#이 C++보다 언제나 빠르다는 것을 강조한 것이 아닙니다. 마지막에도 언급했지만, 별로 신경쓰지 않고 작성한 코드 결과가 어느 경우에는 C#이 더 빠를 수 있다는 것을 말하고 싶은 것입니다.

사실 위의 코드는 MemoryStream에도 굳이 reserve 관련 호출을 하지 않았고 따라서 표면상으로 보면 vector의 상황과 별반 다르지 않습니다. 초보 개발자 입장에서는 얼마든지 저런 식으로 작성할 수 있다는 것입니다.

그리고, 저는 "의미 없다"는 덧글보다는 보통 C#처럼 MemoryStream을 쓸 것 같은 상황에서는 C++의 경우 vector보다는 어떤 다른 자료 구조를 더 자주 사용한다거나, 선호한다거나, 뭐 그런 식의 생산적인 덧글이 달렸으면 좋겠습니다.
정성태
2023-07-12 09시49분
Why does the compiler complain about a missing constructor when I’m just resizing my std::vector to a smaller size?
; https://devblogs.microsoft.com/oldnewthing/20230711-00/?p=108408

당연한 이야기지만, vector<T>.resize 호출 시 해당 T template 타입에는 (암시적이라도) 기본 생성자가 있어야 합니다. 없다면 이런 오류가 발생하는데,

error C2512: 'Thing::Thing': no appropriate default constructor available

설령 크기를 줄이는 목적으로 호출하는 경우라도 컴파일러는 그것을 알 수 없으므로 (사용이 되진 않겠지만) 늘어나기 위한 상황에서 대체할 dummy 인스턴스를 인자로 넣어주거나,

// pass dummy object to keep compiler happy
things.resize(n, dummy_thing); // keep only the first n

아예 크기 축소를 위한 것이라는 의미로 erase를 사용하면 된다고 합니다.

things.erase(things.begin() + n, things.end());

--------------------------------------------------------------------------

(2024-05-23) If you have to create a Windows Runtime Vector from C++/WinRT, do it as late as possible
; https://devblogs.microsoft.com/oldnewthing/20240522-00/?p=109795

WinRT의 경우 IVector를 구현한 multi_threaded_vector를 바로 사용하기보다는 stl:vector를 경유해 초기화하는 것이 성능상 좋다는 내용.
정성태

... 91  92  93  94  95  96  97  98  99  100  101  102  103  [104]  105  ...
NoWriterDateCnt.TitleFile(s)
11325정성태10/14/201719371.NET Framework: 689. CLR 4.0 환경에서 DLL 모듈의 로드 주소(Base address) 알아내는 방법
11324정성태10/13/201720964디버깅 기술: 101. windbg - "*** WARNING: Unable to verify checksum for" 경고 없애는 방법
11322정성태10/13/201718352디버깅 기술: 100. windbg - .NET 4.0 응용 프로그램의 Main 메서드에 Breakpoint 걸기
11321정성태10/11/201719872.NET Framework: 688. NGen 모듈과 .NET Profiler
11320정성태10/11/201720668.NET Framework: 687. COR_PRF_USE_PROFILE_IMAGES 옵션과 NGen의 "profiler-enhanced images" [1]
11319정성태10/11/201728214.NET Framework: 686. C# - string 배열을 담은 구조체를 직렬화하는 방법
11318정성태10/7/201721015VS.NET IDE: 122. 비주얼 스튜디오에서 관리자 권한을 요구하는 C# 콘솔 프로그램 제작 [1]
11317정성태10/4/201726152VC++: 120. std::copy 등의 함수 사용 시 _SCL_SECURE_NO_WARNINGS 에러 발생
11316정성태9/30/201724197디버깅 기술: 99. (닷넷) 프로세스(EXE)에 디버거가 연결되어 있는지 아는 방법 [4]
11315정성태9/29/201740246기타: 68. "시작하세요! C# 6.0 프로그래밍: 기본 문법부터 실전 예제까지" 구매하신 분들을 위한 C# 7.0/7.1 추가 문법 PDF [8]
11314정성태9/28/201722064디버깅 기술: 98. windbg - 덤프 파일로부터 닷넷 버전 확인하는 방법
11313정성태9/25/201719323디버깅 기술: 97. windbg - 메모리 덤프로부터 DateTime 형식의 값을 알아내는 방법파일 다운로드1
11312정성태9/25/201722472.NET Framework: 685. C# - 구조체(값 형식)의 필드를 리플렉션을 이용해 값을 바꾸는 방법파일 다운로드1
11311정성태9/20/201716848.NET Framework: 684. System.Diagnostics.Process 객체의 명시적인 해제 권장
11310정성태9/19/201720299.NET Framework: 683. WPF의 Window 객체를 생성했는데 GC 수집 대상이 안 되는 이유 [3]
11309정성태9/13/201718421개발 환경 구성: 335. Octave의 명령 창에서 실행한 결과를 복사하는 방법
11308정성태9/13/201719469VS.NET IDE: 121. 비주얼 스튜디오에서 일부 텍스트 파일을 무조건 메모장으로만 여는 문제파일 다운로드1
11307정성태9/13/201722023오류 유형: 421. System.Runtime.InteropServices.SEHException - 0x80004005
11306정성태9/12/201720136.NET Framework: 682. 아웃룩 사용자를 위한 중국어 스팸 필터 Add-in
11305정성태9/12/201721589개발 환경 구성: 334. 기존 프로젝트를 Visual Studio를 이용해 Github의 신규 생성된 repo에 올리는 방법 [1]
11304정성태9/11/201718687개발 환경 구성: 333. 3ds Max를 Hyper-V VM에서 실행하는 방법
11303정성태9/11/201721988개발 환경 구성: 332. Inno Setup 파일의 관리자 권한을 제거하는 방법
11302정성태9/11/201718269개발 환경 구성: 331. SQL Server Express를 위한 방화벽 설정
11301정성태9/11/201717130오류 유형: 420. SQL Server Express 연결 오류 - A network-related or instance-specific error occurred while establishing a connection to SQL Server.
11300정성태9/10/201721004.NET Framework: 681. dotnet.exe - run, exec, build, restore, publish 차이점 [3]
11299정성태9/9/201719722개발 환경 구성: 330. Hyper-V VM의 Internal Network를 Private 유형으로 만드는 방법
... 91  92  93  94  95  96  97  98  99  100  101  102  103  [104]  105  ...