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

... 46  47  48  49  50  [51]  52  53  54  55  56  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12665정성태6/9/202117620.NET Framework: 1066. Wslhub.Sdk 사용으로 알아보는 CoInitializeSecurity 사용 제약파일 다운로드1
12664정성태6/9/202115474오류 유형: 723. COM+ PIA 참조 시 "This operation failed because the QueryInterface call on the COM component" 오류
12663정성태6/9/202117873.NET Framework: 1065. Windows Forms - 속성 창의 디자인 설정 지원: 문자열 목록 내에서 항목을 선택하는 TypeConverter 제작파일 다운로드1
12662정성태6/8/202115489.NET Framework: 1064. C# COM 개체를 PIA(Primary Interop Assembly)로써 "Embed Interop Types" 참조하는 방법파일 다운로드1
12661정성태6/4/202127526.NET Framework: 1063. C# - MQTT를 이용한 클라이언트/서버(Broker) 통신 예제 [4]파일 다운로드1
12660정성태6/3/202118221.NET Framework: 1062. Windows Forms - 폼 내에서 발생하는 마우스 이벤트를 자식 컨트롤 영역에 상관없이 수신하는 방법 [1]파일 다운로드1
12659정성태6/2/202119166Linux: 40. 우분투 설치 후 MBR 디스크 드라이브 여유 공간이 인식되지 않은 경우 - Logical Volume Management
12658정성태6/2/202117018Windows: 194. Microsoft Store에 있는 구글의 공식 Youtube App
12657정성태6/2/202117765Windows: 193. 윈도우 패키지 관리자 - winget 설치
12656정성태6/1/202116102.NET Framework: 1061. 서버 유형의 COM+에 적용할 수 없는 Server GC
12655정성태6/1/202114669오류 유형: 722. windbg/sos - savemodule - Fail to read memory
12654정성태5/31/202115390오류 유형: 721. Hyper-V - Saved 상태의 VM을 시작 시 오류 발생
12653정성태5/31/202118653.NET Framework: 1060. 닷넷 GC에 새롭게 구현되는 DPAD(Dynamic Promotion And Demotion for GC)
12652정성태5/31/202116149VS.NET IDE: 164. Visual Studio - Web Deploy로 Publish 시 암호창이 매번 뜨는 문제
12651정성태5/31/202116300오류 유형: 720. PostgreSQL - ERROR: 22P02: malformed array literal: "..."
12650정성태5/17/202115666기타: 82. OpenTabletDriver의 버튼에 더블 클릭을 매핑 및 게임에서의 지원 방법
12649정성태5/16/202117843.NET Framework: 1059. 세대 별 GC(Garbage Collection) 방식에서 Card table의 사용 의미 [1]
12648정성태5/16/202116666사물인터넷: 66. PC -> FTDI -> NodeMCU v1 ESP8266 기기를 UART 핀을 연결해 직렬 통신하는 방법파일 다운로드1
12647정성태5/15/202116811.NET Framework: 1058. C# - C++과의 연동을 위한 구조체의 fixed 배열 필드 사용파일 다운로드1
12646정성태5/15/202115643사물인터넷: 65. C# - Arduino IDE의 Serial Monitor 기능 구현파일 다운로드1
12645정성태5/14/202115733사물인터넷: 64. NodeMCU v1 ESP8266 - LittleFS를 이용한 와이파이 접속 정보 업데이트파일 다운로드1
12644정성태5/14/202116993오류 유형: 719. 윈도우 - 제어판의 "프로그램 및 기능" / "Windows 기능 켜기/끄기" 오류 0x800736B3
12643정성태5/14/202117117오류 유형: 718. 서버 유형의 COM+ 사용 시 0x80080005(Server execution failed) 오류 발생
12642정성태5/14/202118598오류 유형: 717. The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
12641정성태5/13/202117432디버깅 기술: 179. 윈도우용 .NET Core 3 이상에서 Windbg의 sos 사용법
12640정성태5/13/202121150오류 유형: 716. RDP 연결 - Because of a protocol error (code: 0x112f), the remote session will be disconnected. [1]
... 46  47  48  49  50  [51]  52  53  54  55  56  57  58  59  60  ...