Microsoft MVP성태의 닷넷 이야기
.NET Framework: 374. C#과 비교한 C++ STL vector 성능 [링크 복사], [링크+제목 복사],
조회: 31288
글쓴 사람
정성태 (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를 경유해 초기화하는 것이 성능상 좋다는 내용.
정성태

... [121]  122  123  124  125  126  127  128  129  130  131  132  133  134  135  ...
NoWriterDateCnt.TitleFile(s)
10900정성태2/19/201622071.NET Framework: 548. Linq는 결국 메서드 호출! [3]파일 다운로드1
10899정성태2/17/201623391개발 환경 구성: 282. kernel32.dll, kernel32legacy.dll, api-ms-win-core-sysinfo-l1-2-0.dll [1]
10898정성태2/17/201621890.NET Framework: 547. PerformanceCounter의 InstanceName 지정 시 주의 사항파일 다운로드1
10897정성태2/17/201621267디버깅 기술: 76. windbg 분석 사례 - 닷넷 프로파일러의 GC 콜백 부하
10896정성태2/17/201622377오류 유형: 320. FATAL: 28000: no pg_hba.conf entry for host "fe80::1970:8120:695:a41e%12"
10895정성태2/17/201621178.NET Framework: 546. System.AppDomain으로부터 .NET Profiler의 AppDomainID 구하는 방법 [1]
10894정성태2/17/201621882오류 유형: 319. Visual Studio에서 찾기는 성공하지만 해당 소스 코드 정보가 보이지 않는 경우
10893정성태2/16/201620599.NET Framework: 545. 닷넷 - 특정 클래스가 로드되었는지 여부를 알 수 있을까? - 두 번째 이야기
10892정성태2/16/201621142오류 유형: 318. 탐색기에서 폴더 생성/삭제 시 몇 초 동안 멈추는 현상
10891정성태2/16/201624194VC++: 95. 내 CPU가 MPX/SGX를 지원할까요? [1]
10890정성태2/15/201624072.NET Framework: 544. C# 5의 Caller Info를 .NET 4.5 미만의 응용 프로그램에 적용하는 방법 [5]
10889정성태2/14/201620388.NET Framework: 543. C++의 inline asm 사용을 .NET으로 포팅하는 방법 - 두 번째 이야기파일 다운로드1
10888정성태2/14/201618706.NET Framework: 542. 닷넷 - 특정 클래스가 로드되었는지 여부를 알 수 있을까?
10887정성태2/3/201619407VC++: 94. MPX(Memory Protection Extensions) 테스트파일 다운로드1
10886정성태2/3/201620646개발 환경 구성: 281. Intel MPX Runtime Driver 수동 설치
10885정성태2/2/201620348오류 유형: 317. Sybase.Data.AseClient.AseException: The command has timed out.
10884정성태1/11/201621558개발 환경 구성: 280. 닷넷에서 SAP Adaptive Server Enterprise 데이터베이스 사용파일 다운로드1
10882정성태1/6/201620860Windows: 113. 윈도우의 2179, 26143, 47001 TCP 포트 사용 [1]
10881정성태1/3/201622219오류 유형: 316. 윈도우 10 - 바탕/돋음 체가 사라져 한글이 깨지는 현상 [2]
10880정성태12/16/201519991오류 유형: 315. 닷넷 프로파일러의 오류 코드 정보
10879정성태12/16/201521946오류 유형: 314. Error : DEP0700 : Registration of the app failed. error 0x80070005
10878정성태12/9/201524970디버깅 기술: 75. UWP(유니버설 윈도우 플랫폼) 앱에서 global::System.Diagnostics.Debugger.Break 예외 발생 시 대응 방법
10877정성태12/9/201529349VC++: 93. std::thread 사용 시 R6010 오류 [2]
10876정성태11/26/201525476.NET Framework: 541. SignedXml을 이용한 ds:Signature만드는 방법 [3]파일 다운로드1
10875정성태11/26/201530425개발 환경 구성: 279. signtool.exe의 다중 서명 기능 [2]
10874정성태11/26/201526400개발 환경 구성: 278. 인증서와 인증서를 이용한 코드 사인의 해시 구분
... [121]  122  123  124  125  126  127  128  129  130  131  132  133  134  135  ...