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

... 151  152  153  154  155  156  157  158  159  [160]  161  162  163  164  165  ...
NoWriterDateCnt.TitleFile(s)
1048정성태5/27/201132235개발 환경 구성: 123. Apache 소스를 윈도우 환경에서 빌드하기
1047정성태5/27/201126090.NET Framework: 217. Firebird ALinq Provider - 날짜 필드에 대한 낙관적 동시성 쿼리 오류
1046정성태5/26/201130733.NET Framework: 216. 라이선스까지도 뛰어넘는 .NET Profiler [5]
1045정성태5/24/201131845.NET Framework: 215. 닷넷 System.ComponentModel.LicenseManager를 이용한 라이선스 적용 [1]파일 다운로드1
1044정성태5/24/201132394오류 유형: 122. zlib 빌드 오류 - inflate.obj : error LNK2001: unresolved external symbol _inflate_fast
1043정성태5/24/201131345.NET Framework: 214. 무료 Linq Provider - DbLinq를 이용한 Firebird 접근파일 다운로드1
1042정성태5/23/201137680개발 환경 구성: 122. PHP 소스를 윈도우 환경에서 빌드하기
1041정성태5/22/201128604.NET Framework: 213. Linq To SQL - ALinq Provider를 이용하여 Firebird 사용파일 다운로드1
1040정성태5/21/201138935개발 환경 구성: 121. .NET 개발자가 처음 설치해 본 Apache + PHP [2]
1039정성태5/17/201131627.NET Framework: 212. Firebird 데이터베이스와 ADO.NET [2]파일 다운로드1
1038정성태5/16/201133605개발 환경 구성: 120. .NET 프로그래머에게도 유용한 Firebird 무료 데이터베이스 [2]
1037정성태5/11/201128420개발 환경 구성: 119. Visual Studio Professional 이하 버전에서도 TFS의 정적 코드 분석 정책 연동이 가능할까? [3]
1036정성태5/7/201194245오류 유형: 121. Access DB에 대한 32bit/64bit OLE DB Provider 관련 오류 [11]
1035정성태5/7/201128988오류 유형: 120. File cannot be opened. Ensure it is a valid Data Link file.
1034정성태5/2/201126053.NET Framework: 211. 파일 잠금 없이 .NET 어셈블리의 버전을 구하는 방법 [2]파일 다운로드1
1033정성태5/1/201131749웹: 19. IIS Express - appcmd.exe를 이용한 applicationHost.config 변경 [2]
1032정성태5/1/201128387웹: 18. IIS Express를 NT 서비스로 변경
1031정성태4/30/201129546웹: 17. IIS Express - "IIS Installed Versions Manager Interface"의 IIISExpressProcessUtility 구하는 방법 [1]파일 다운로드1
1030정성태4/30/201151801개발 환경 구성: 118. IIS Express - localhost 이외의 호스트 이름으로 접근하는 방법 [4]파일 다운로드1
1029정성태4/28/201140929개발 환경 구성: 117. XCopy에서 파일/디렉터리 확인 질문 없애기 [2]
1028정성태4/27/201138330오류 유형: 119. Visual Studio 2010 SP1 설치 후 Windows Phone 개발자 도구로 인한 재설치 문제 [3]
1027정성태4/25/201127503디버깅 기술: 40. 상황별 GetFunctionPointer 반환값 정리 - x86파일 다운로드1
1026정성태4/25/201145791디버깅 기술: 39. DebugDiag 1.1을 사용한 덤프 분석 [7]
1025정성태4/24/201127856개발 환경 구성: 116. IIS 7 관리자 - Active Directory Certification Authority로부터 SSL 사이트 인증서 받는 방법 [2]
1024정성태4/22/201129191오류 유형: 118. Windows 2008 서버에서 Event Viewer / PowerShell 실행 시 비정상 종료되는 문제 [1]
1023정성태4/20/201130073.NET Framework: 210. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 [1]
... 151  152  153  154  155  156  157  158  159  [160]  161  162  163  164  165  ...