Microsoft MVP성태의 닷넷 이야기
.NET Framework: 374. C#과 비교한 C++ STL vector 성능 [링크 복사], [링크+제목 복사],
조회: 31208
글쓴 사람
정성태 (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)
1704정성태7/2/201421634.NET Framework: 447. w3wp.exe AppPool 재생(recycle)하는 방법 정리
1703정성태7/2/201422469.NET Framework: 446. Assembly.Load를 이용해 GAC에 등록된 어셈블리를 로드하는 방법 [1]파일 다운로드1
1702정성태6/23/201422193Phone: 11. Xamarin.Forms - 2. XAML을 이용한 페이지 개발파일 다운로드1
1701정성태6/23/201434383개발 환경 구성: 229. .NET Reflector + Reflexil 도구를 이용해 DLL 코드 변경 [4]
1700정성태6/23/201421232VS.NET IDE: 89. Visual Studio에서 기본 제공되는 성능 프로파일 [2]
1699정성태6/22/201424037Phone: 10. Xamarin.Forms - 1. Forms 시작하기 [2]파일 다운로드1
1698정성태6/22/201426043.NET Framework: 445. [부연 설명] 쉬운 C# 코드를 어럽게 이해하기 [2]
1697정성태6/22/201421285VS.NET IDE: 88. Visual Studio에서 직접 컴파일하는 IL 언어 확장 도구 - IL Support
1696정성태6/22/201421133.NET Framework: 444. clojure와 C#을 통해 이해하는 Sequence와 Vector 형식의 차이점 [1]
1695정성태6/21/201420137개발 환경 구성: 228. PowerShell ISE에서 (입력 기능이 있는) 콘솔 응용 프로그램을 시작하는 방법
1694정성태6/21/201421301개발 환경 구성: 227. 닷넷 용 ClojureCLR 개발환경 설정
1693정성태6/20/201421626개발 환경 구성: 226. Clojure 언어의 윈도우 개발환경 설정
1692정성태6/19/201432223오류 유형: 231. Visual Studio 2013 한글 버전 설치 오류 - The form specified for the subject is not one supported or known by the specified trust provider
1691정성태6/18/201427441개발 환경 구성: 225. 유닉스 계열의 tail 명령어가 제공되는 PowerShell [1]
1690정성태6/18/201430230개발 환경 구성: 224. DirectShow 예제 구하는 방법 [3]
1689정성태6/18/201427063오류 유형: 230. C++ 가변 인자 사용시 va_start 파라미터 전달 방법 [2]
1688정성태6/15/201420607오류 유형: 229. 갤럭시 노트 3 환경에서 Xamarin 앱 배포 충돌
1687정성태6/15/201426642개발 환경 구성: 223. PowerShell로 Visual Studio 빌드 스크립트 작성파일 다운로드1
1686정성태6/12/201424318Windows: 96. 윈도우 8 - 그림 암호를 이용해 로그인 시 지연 현상을 해결하는 방법 [1]
1685정성태6/10/201431098.NET Framework: 443. 자바 8과 C#의 람다(Lambda) 지원에 대한 비교 [12]
1684정성태6/9/201441262.NET Framework: 442. C# - 시스템의 CPU 사용량 및 프로세스(EXE)의 CPU 사용량 알아내는 방법 [5]파일 다운로드1
1683정성태6/2/201420802오류 유형: 228. CLR4 보안 - yield 구문 내에서 SecurityCritical 메서드 사용 불가 [2]파일 다운로드1
1682정성태6/1/201426027.NET Framework: 441. .NET CLR4 보안 모델 - 3. CLR4 보안 모델에서의 APTCA 역할파일 다운로드2
1681정성태6/1/201421878.NET Framework: 440. .NET CLR4 보안 모델 - 2. 샌드박스(Sandbox)을 이용한 보안 [2]파일 다운로드1
1680정성태6/1/201421359.NET Framework: 439. .NET CLR4 보안 모델 - 1. "Security Level 2"란?파일 다운로드1
1679정성태5/31/201420485.NET Framework: 438. .NET CLR2 보안 모델에서의 APTCA 역할파일 다운로드1
... 121  122  123  124  125  126  127  128  129  130  131  132  133  [134]  135  ...