내 요구에 가장 적합한 STL 컨테이너는 무엇입니까? 기본적으로 가장 오래된 요소 (약 백만 시간)를 사용 push_back하면서 지속적으로 새로운 요소를 포함하는 10 개의 요소 너비 컨테이너가 pop_front있습니다.
현재 std::deque작업에 a 를 사용하고 있지만 std::list자체를 재 할당 할 필요가 없기 때문에 a 가 더 효율적 인지 궁금 합니다 (또는 a std::deque를 a로 착각하고있을 수도 있습니다 std::vector). 아니면 내 필요에 맞는 더 효율적인 컨테이너가 있습니까?
추신 : 랜덤 액세스가 필요하지 않습니다
std::deque재 할당되지 않습니다. a std::list와 a 의 하이브리드로 a std::vector보다 큰 청크를 할당 std::list하지만 std::vector.
답변:
무수히 많은 답변이 있기 때문에 혼란 스러울 수 있지만 요약하면 다음과 같습니다.
를 사용합니다 std::queue. 그 이유는 간단합니다. FIFO 구조이기 때문입니다. FIFO를 원하면 std::queue.
그것은 당신의 의도를 다른 사람에게, 심지어 당신 자신에게도 분명하게합니다. A std::list또는 std::deque하지 않습니다. 목록은 FIFO 구조가 수행 deque할 수 있는 작업이 아닌 임의의 위치에 삽입 및 제거 할 수 있으며, 이는 FIFO 구조가 수행 할 수없는 일이기도합니다.
이것이 당신이 queue.
이제 성능에 대해 물었습니다. 첫째, 항상 다음과 같은 중요한 경험 법칙을 기억하십시오. 좋은 코드는 우선, 성능은 마지막입니다.
그 이유는 간단합니다. 청결과 우아함이 거의 항상 마지막으로 끝나기 전에 성능을 위해 노력하는 사람들입니다. 그들의 코드는 아무 것도 얻기 위해 좋은 것을 모두 버리기 때문에 엉망진창이됩니다.
읽기 쉽고 좋은 코드를 먼저 작성하면 대부분의 성능 문제가 저절로 해결됩니다. 나중에 성능이 부족하다는 사실을 알게되면 이제는 깔끔하고 멋진 코드에 프로파일 러를 쉽게 추가하고 문제가 어디에 있는지 알아낼 수 있습니다.
즉 std::queue, 어댑터 일뿐입니다. 안전한 인터페이스를 제공하지만 내부에는 다른 컨테이너를 사용합니다. 이 기본 컨테이너를 선택할 수 있으며 이는 상당한 유연성을 허용합니다.
그렇다면 어떤 기본 컨테이너를 사용해야합니까? 우리는 알고 std::list그리고 std::deque둘 다 필요한 기능을 제공 ( push_back(), pop_front(), 및 front()), 그래서 우리는 어떻게 결정합니까?
첫째, 메모리 할당 (및 할당 해제)은 일반적으로 OS로 가서 무언가를 요청하기 때문에 빠른 작업이 아니라는 점을 이해하십시오. A list는 무언가가 추가 될 때마다 메모리를 할당하고, 사라질 때 할당을 해제해야합니다.
deque반면 A 는 청크로 할당됩니다. 그것은보다 적게 할당합니다 list. 목록으로 생각하면 각 메모리 청크는 여러 노드를 보유 할 수 있습니다. (물론, 어떻게 작동하는지 정말 배우는 것이 좋습니다 .)
그래서, 그것만으로 deque는 더 잘 수행되어야합니다. 왜냐하면 그것은 자주 기억을 다루지 않기 때문입니다. 일정한 크기의 데이터를 처리한다는 사실과 섞여서 데이터를 처음 통과 한 후에는 할당 할 필요가없는 반면 목록은 지속적으로 할당 및 할당 해제됩니다.
두 번째로 이해해야 할 것은 캐시 성능 입니다. RAM으로 나가는 것은 느리기 때문에 CPU가 정말로 필요할 때 메모리 덩어리를 캐시로 되돌림으로써이 시간을 최대한 활용합니다. deque는 메모리 청크에 할당 되기 때문에이 컨테이너의 요소에 액세스하면 CPU가 나머지 컨테이너도 다시 가져올 가능성이 있습니다. 이제 deque데이터가 캐시에 있기 때문에에 대한 추가 액세스 가 빨라집니다.
이것은 데이터가 한 번에 하나씩 할당되는 목록과 다릅니다. 이는 데이터가 메모리의 모든 위치에 분산 될 수 있으며 캐시 성능이 나빠질 수 있음을 의미합니다.
따라서이를 고려하면 a deque가 더 나은 선택이어야합니다. 이것이 .NET Framework를 사용할 때 기본 컨테이너 인 이유 queue입니다. 즉, 이것은 여전히 (매우) 교육을받은 추측 일뿐입니다.이 코드를 프로파일 링해야합니다 deque. 한 테스트를 사용하고 다른 테스트를 사용하여 list확실히 알 수 있습니다.
하지만 기억하세요 : 깨끗한 인터페이스로 코드를 작업 한 다음 성능에 대해 걱정하세요.
John은 list또는deque 성능 저하의 원인이됩니다. 다시 한 번, 그도 나도 직접 프로파일 링하지 않고 확실히 말할 수는 없지만 컴파일러가 호출을 인라인 할 가능성이 queue있습니다. 즉,라고 말하면 함수 호출을 완전히 건너 뛰고 queue.push()실제로라고 말할 것 queue.container.push_back()입니다.
다시 한 번, 이것은 교육 된 추측 일 뿐이지 만 queue기본 컨테이너를 원시 상태로 사용하는 것과 비교할 때를 사용하면 성능이 저하되지 않습니다. 전에 말했듯이를 사용하십시오 queue. 왜냐하면 깨끗하고 사용하기 쉽고 안전하기 때문이며 실제로 문제 프로필 및 테스트가되는 경우입니다.
확인하십시오 std::queue. 기본 컨테이너 유형을 래핑하고 기본 컨테이너는 std::deque입니다.
queue그 유형입니다. 좋은 코드는 먼저, 성능은 나중에. 지옥, 대부분의 성능은 애초에 좋은 코드를 사용하는 데서 나온다.
queue, 내가 말했듯이 안전 장치의 껍질을 벗기는 것은 성능을 향상시키지 않을 것입니다. list성능이 더 나빠질을 제안 하셨습니다.
성능이 정말로 중요한 경우 Boost 순환 버퍼 라이브러리를 확인하십시오 .
가장 오래된 요소 (약 백만 시간)를 사용
push_back하면서 계속해서 새로운 요소를pop_front만듭니다.
백만은 실제로 컴퓨팅에서 큰 숫자가 아닙니다. 다른 사람들이 제안했듯이를 std::queue첫 번째 솔루션으로 사용 하십시오. 너무 느린 경우에는 프로파일 러를 사용하여 병목 현상을 식별하고 (추측하지 마십시오!) 동일한 인터페이스를 가진 다른 컨테이너를 사용하여 다시 구현하십시오.
를 사용 std::queue하되 두 표준 Container클래스 의 성능 절충점을 알고 있어야 합니다.
기본적 std::queue으로은 std::deque. 일반적으로 많은 수의 항목을 포함하는 대기열 수가 적을 때 좋은 성능을 제공합니다. 이는 일반적인 경우입니다.
그러나 std :: deque 구현에 눈이 멀지 마십시오 . 구체적으로 특별히:
"... deque는 일반적으로 최소한의 메모리 비용이 큽니다. 하나의 요소 만 포함하는 deque는 전체 내부 배열을 할당해야합니다 (예 : 64 비트 libstdc ++에서 개체 크기의 8 배, 개체 크기의 16 배 또는 4096 바이트 중 더 큰 쪽). , 64 비트 libc ++). "
이를 해결하려면 대기열 항목이 대기열에 넣고 싶은 항목이라고 가정합니다. 즉, 크기가 상당히 작다고 가정하면 각각 30,000 개의 항목을 포함하는 4 개의 대기열 std::deque이있는 경우 구현이 선택 옵션이됩니다. 반대로, 각각 4 개의 항목을 포함하는 30,000 개의 대기열이있는 경우 해당 시나리오 std::list에서 std::deque오버 헤드를 상각하지 않으므로 구현이 최적 일 것 입니다.
특정 조건에서 캐시가 어떻게 왕인지, Stroustrup이 연결 목록을 싫어하는지 등에 대한 많은 의견을 읽을 수 있습니다.이 모든 것이 사실입니다. 맹목적으로 받아들이지 마십시오. 두 번째 시나리오에서는 기본 std::deque구현이 수행 될 가능성이 거의 없습니다 . 사용량을 평가하고 측정하십시오.
이 경우는 직접 작성할 수있을 정도로 간단합니다. 다음은 STL 사용이 너무 많은 공간을 차지하는 마이크로 컨트롤러 상황에서 잘 작동하는 것입니다. 인터럽트 핸들러에서 메인 루프로 데이터와 신호를 전달하는 좋은 방법입니다.
// FIFO with circular buffer
#define fifo_size 4
class Fifo {
uint8_t buff[fifo_size];
int writePtr = 0;
int readPtr = 0;
public:
void put(uint8_t val) {
buff[writePtr%fifo_size] = val;
writePtr++;
}
uint8_t get() {
uint8_t val = NULL;
if(readPtr < writePtr) {
val = buff[readPtr%fifo_size];
readPtr++;
// reset pointers to avoid overflow
if(readPtr > fifo_size) {
writePtr = writePtr%fifo_size;
readPtr = readPtr%fifo_size;
}
}
return val;
}
int count() { return (writePtr - readPtr);}
};