ฉันได้ยินว่ามีคนสองสามคนแสดงความกังวลเกี่ยวกับตัวดำเนินการ "+" ใน std :: string และวิธีแก้ปัญหาต่างๆเพื่อเร่งการเชื่อมต่อ สิ่งเหล่านี้จำเป็นจริงๆหรือไม่? ถ้าเป็นเช่นนั้นวิธีที่ดีที่สุดในการเชื่อมสตริงใน C ++ คืออะไร?

การทำงานพิเศษอาจไม่คุ้มค่าเว้นแต่คุณจะต้องการประสิทธิภาพจริงๆ คุณอาจจะมีประสิทธิภาพที่ดีขึ้นมากเพียงแค่ใช้ตัวดำเนินการ + = แทน

หลังจากข้อจำกัดความรับผิดชอบนั้นฉันจะตอบคำถามที่แท้จริงของคุณ ...

ประสิทธิภาพของคลาสสตริง STL ขึ้นอยู่กับการนำ STL ที่คุณใช้อยู่

คุณสามารถรับประกันประสิทธิภาพและควบคุมตัวเองได้มากขึ้นด้วยการเชื่อมต่อด้วยตนเองผ่านฟังก์ชั่นในตัว c

เหตุใดตัวดำเนินการ + จึงไม่มีประสิทธิภาพ:

ดูอินเทอร์เฟซนี้:

template <class charT, class traits, class Alloc>
basic_string<charT, traits, Alloc>
operator+(const basic_string<charT, traits, Alloc>& s1,
          const basic_string<charT, traits, Alloc>& s2)

คุณจะเห็นว่ามีการส่งคืนวัตถุใหม่หลังจากแต่ละ + นั่นหมายความว่าจะมีการใช้บัฟเฟอร์ใหม่ในแต่ละครั้ง หากคุณกำลังดำเนินการพิเศษ + จำนวนมากมันจะไม่มีประสิทธิภาพ

ทำไมคุณสามารถทำให้มีประสิทธิภาพมากขึ้น:

• คุณรับประกันประสิทธิภาพแทนที่จะไว้วางใจให้ผู้รับมอบสิทธิ์ดำเนินการอย่างมีประสิทธิภาพให้กับคุณ
• คลาส std :: string ไม่รู้อะไรเลยเกี่ยวกับขนาดสูงสุดของสตริงของคุณและความถี่ที่คุณจะเชื่อมต่อกับสตริงนั้น คุณอาจมีความรู้นี้และสามารถทำสิ่งต่างๆได้จากการมีข้อมูลนี้ ซึ่งจะนำไปสู่การจัดสรรใหม่น้อยลง
• คุณจะควบคุมบัฟเฟอร์ด้วยตนเองดังนั้นคุณจึงมั่นใจได้ว่าคุณจะไม่คัดลอกสตริงทั้งหมดลงในบัฟเฟอร์ใหม่เมื่อคุณไม่ต้องการให้สิ่งนั้นเกิดขึ้น
• คุณสามารถใช้สแต็กสำหรับบัฟเฟอร์แทนฮีปซึ่งมีประสิทธิภาพมากกว่ามาก
• ตัวดำเนินการ string + จะสร้างอ็อบเจ็กต์สตริงใหม่และส่งคืนด้วยเหตุนี้โดยใช้บัฟเฟอร์ใหม่

ข้อควรพิจารณาในการใช้งาน:

• ติดตามความยาวสตริง
• ให้ตัวชี้ไปที่จุดสิ้นสุดของสตริงและจุดเริ่มต้นหรือเพียงแค่จุดเริ่มต้นและใช้จุดเริ่มต้น + ความยาวเป็นออฟเซ็ตเพื่อค้นหาจุดสิ้นสุดของสตริง
• ตรวจสอบให้แน่ใจว่าบัฟเฟอร์ที่คุณจัดเก็บสตริงของคุณมีขนาดใหญ่พอคุณจึงไม่จำเป็นต้องจัดสรรข้อมูลใหม่
• ใช้ strcpy แทน strcat ดังนั้นคุณจึงไม่จำเป็นต้องวนซ้ำตามความยาวของสตริงเพื่อค้นหาจุดสิ้นสุดของสตริง

โครงสร้างข้อมูลเชือก:

หากคุณต้องการได้อย่างรวดเร็วจริงๆ concatenations พิจารณาใช้โครงสร้างข้อมูลเชือก

จองพื้นที่สุดท้ายของคุณก่อนจากนั้นใช้วิธีต่อท้ายด้วยบัฟเฟอร์ ตัวอย่างเช่นสมมติว่าคุณคาดหวังให้ความยาวสตริงสุดท้ายคือ 1 ล้านอักขระ:

std::string s;
s.reserve(1000000);

while (whatever)
{
  s.append(buf,len);
}

ฉันจะไม่กังวลเกี่ยวกับมัน หากคุณทำแบบวนซ้ำสตริงจะจัดสรรหน่วยความจำล่วงหน้าเสมอเพื่อลดการจัดสรรใหม่ - เพียงใช้operator+=ในกรณีนั้น และถ้าคุณทำด้วยตนเองสิ่งนี้หรือนานกว่านั้น

a + " : " + c

จากนั้นเป็นการสร้าง Temporaries แม้ว่าคอมไพเลอร์จะสามารถกำจัดสำเนาค่าส่งคืนบางส่วนได้ นั่นเป็นเพราะในการเรียกแบบต่อเนื่องoperator+ไม่ทราบว่าพารามิเตอร์อ้างอิงอ้างอิงอ็อบเจ็กต์ที่มีชื่อหรือส่งคืนชั่วคราวจากการoperator+เรียกใช้ย่อย ฉันไม่ควรกังวลเกี่ยวกับเรื่องนี้ก่อนที่จะไม่ได้ทำโปรไฟล์ก่อน แต่ลองมาเป็นตัวอย่างเพื่อแสดงให้เห็นว่า อันดับแรกเราแนะนำวงเล็บเพื่อให้การเชื่อมโยงชัดเจน ฉันใส่อาร์กิวเมนต์โดยตรงหลังจากการประกาศฟังก์ชันที่ใช้เพื่อความชัดเจน ด้านล่างนี้ฉันจะแสดงว่านิพจน์ผลลัพธ์คืออะไร:

((a + " : ") + c) 
calls string operator+(string const&, char const*)(a, " : ")
  => (tmp1 + c)

ตอนนี้นอกเหนือจากนั้นtmp1คือสิ่งที่ส่งกลับมาจากการเรียกตัวดำเนินการครั้งแรก + พร้อมด้วยอาร์กิวเมนต์ที่แสดง เราถือว่าคอมไพเลอร์ฉลาดมากและปรับสำเนาค่าส่งคืนให้เหมาะสม ดังนั้นเราจึงจบลงด้วยสตริงใหม่หนึ่งที่มีการเรียงต่อกันของและa " : "ตอนนี้สิ่งนี้เกิดขึ้น:

(tmp1 + c)
calls string operator+(string const&, string const&)(tmp1, c)
  => tmp2 == <end result>

เปรียบเทียบกับสิ่งต่อไปนี้:

std::string f = "hello";
(f + c)
calls string operator+(string const&, string const&)(f, c)
  => tmp1 == <end result>

มันใช้ฟังก์ชันเดียวกันสำหรับสตริงชั่วคราวและสตริงที่มีชื่อ! ดังนั้นคอมไพเลอร์จึงต้องคัดลอกอาร์กิวเมนต์ไปยังสตริงใหม่และต่อท้ายและส่งคืนจากเนื้อหาของoperator+. ไม่สามารถใช้หน่วยความจำชั่วคราวและผนวกเข้ากับสิ่งนั้นได้ ยิ่งนิพจน์ใหญ่เท่าไหร่ก็ยิ่งต้องทำสำเนาสตริงมากขึ้นเท่านั้น

Visual Studio และ GCC ถัดไปจะรองรับความหมายการเคลื่อนที่ของ c ++ 1x (การเสริมความหมายของการคัดลอก ) และการอ้างอิงค่า rvalue เป็นการเพิ่มการทดลอง ซึ่งช่วยให้ทราบว่าพารามิเตอร์อ้างถึงชั่วคราวหรือไม่ สิ่งนี้จะทำให้การเพิ่มดังกล่าวรวดเร็วอย่างน่าอัศจรรย์เนื่องจากสิ่งที่กล่าวมาทั้งหมดจะจบลงใน "add-pipeline" อันเดียวโดยไม่มีสำเนา

หากกลายเป็นคอขวดคุณยังสามารถทำได้

 std::string(a).append(" : ").append(c) ...

การappendโทรต่อท้ายอาร์กิวเมนต์*thisและส่งคืนการอ้างอิงถึงตัวเอง ดังนั้นจึงไม่มีการคัดลอกชั่วคราว หรืออีกวิธีหนึ่งคือoperator+=สามารถใช้ได้ แต่คุณจะต้องมีวงเล็บที่น่าเกลียดเพื่อแก้ไขลำดับความสำคัญ

สำหรับแอปพลิเคชันส่วนใหญ่มันจะไม่สำคัญ เพียงแค่เขียนโค้ดของคุณโดยไม่รู้ตัวว่าตัวดำเนินการ + ทำงานอย่างไรอย่างมีความสุขและลงมือทำเองก็ต่อเมื่อมันกลายเป็นคอขวดที่ชัดเจน

ซึ่งแตกต่างจาก. NET System.Strings, C ++ ของ std :: strings สามารถเปลี่ยนแปลงได้ดังนั้นจึงสามารถสร้างได้ด้วยการเชื่อมต่อแบบง่าย ๆ เช่นเดียวกับวิธีการอื่น ๆ

บางที std :: stringstream แทน?

แต่ฉันเห็นด้วยกับความเชื่อมั่นที่ว่าคุณควรรักษาไว้ให้ดีและเข้าใจได้จากนั้นโปรไฟล์เพื่อดูว่าคุณกำลังมีปัญหาจริงๆหรือไม่

ในImperfect C ++ Matthew Wilson นำเสนอตัวเชื่อมต่อสตริงแบบไดนามิกที่คำนวณล่วงหน้าความยาวของสตริงสุดท้ายเพื่อให้มีการจัดสรรเพียงครั้งเดียวก่อนที่จะเชื่อมต่อส่วนทั้งหมด นอกจากนี้เรายังสามารถใช้ concatenator คงที่ด้วยการเล่นกับแม่แบบการแสดงออก

ความคิดแบบนั้นได้ถูกนำไปใช้ใน STLport std :: การใช้งานสตริงซึ่งไม่เป็นไปตามมาตรฐานเนื่องจากการแฮ็กที่แม่นยำนี้

std::string operator+จัดสรรสตริงใหม่และคัดลอกสองสตริงตัวถูกดำเนินการทุกครั้ง ทำซ้ำหลาย ๆ ครั้งและมีราคาแพง O (n)

std::string appendและoperator+=ในทางกลับกันกระแทกความจุ 50% ทุกครั้งที่สตริงต้องเติบโต ซึ่งช่วยลดจำนวนการจัดสรรหน่วยความจำและการคัดลอกลงอย่างมาก O (log n)

สำหรับสายเล็กมันไม่สำคัญ หากคุณมีสตริงขนาดใหญ่คุณควรจัดเก็บสตริงเหล่านี้เนื่องจากเป็นเวกเตอร์หรือในคอลเลคชันอื่น ๆ เป็นส่วน ๆ และเพิ่มอัลกอริทึมของคุณเพื่อทำงานกับชุดข้อมูลดังกล่าวแทนที่จะเป็นสตริงขนาดใหญ่

ฉันชอบ std :: ostringstream สำหรับการเชื่อมต่อที่ซับซ้อน

เช่นเดียวกับสิ่งต่างๆส่วนใหญ่การไม่ทำอะไรบางอย่างนั้นง่ายกว่าการทำ

หากคุณต้องการส่งออกสตริงขนาดใหญ่ไปยัง GUI อาจเป็นไปได้ว่าสิ่งใดก็ตามที่คุณส่งออกมาสามารถจัดการกับสตริงเป็นชิ้น ๆ ได้ดีกว่าสตริงขนาดใหญ่ (ตัวอย่างเช่นการต่อข้อความในโปรแกรมแก้ไขข้อความ - โดยปกติจะแยกบรรทัดกัน โครงสร้าง).

หากคุณต้องการส่งออกไปยังไฟล์ให้สตรีมข้อมูลแทนที่จะสร้างสตริงขนาดใหญ่และส่งออกข้อมูลนั้น

ฉันไม่เคยพบว่าจำเป็นต้องทำการเชื่อมต่อให้เร็วขึ้นหากฉันลบการเชื่อมต่อที่ไม่จำเป็นออกจากโค้ดที่ช้า

น่าจะเป็นประสิทธิภาพที่ดีที่สุดหากคุณจัดสรรพื้นที่ (สำรอง) ไว้ล่วงหน้าในสตริงผลลัพธ์

template<typename... Args>
std::string concat(Args const&... args)
{
    size_t len = 0;
    for (auto s : {args...})  len += strlen(s);

    std::string result;
    result.reserve(len);    // <--- preallocate result
    for (auto s : {args...})  result += s;
    return result;
}

การใช้งาน:

std::string merged = concat("This ", "is ", "a ", "test!");

อาร์เรย์ของอักขระธรรมดาที่ห่อหุ้มในคลาสที่ติดตามขนาดอาร์เรย์และจำนวนไบต์ที่จัดสรรนั้นเร็วที่สุด

เคล็ดลับคือการจัดสรรขนาดใหญ่เพียงครั้งเดียวเมื่อเริ่มต้น

ที่

https://github.com/pedro-vicente/table-string

เกณฑ์มาตรฐาน

สำหรับ Visual Studio 2015 สร้างดีบัก x86 การปรับปรุงทางการเงินบน C ++ std :: string

| API                   | Seconds           
| ----------------------|----| 
| SDS                   | 19 |  
| std::string           | 11 |  
| std::string (reserve) | 9  |  
| table_str_t           | 1  |  

คุณสามารถลองใช้ตัวนี้ด้วยการจองหน่วยความจำสำหรับแต่ละรายการ:

namespace {
template<class C>
constexpr auto size(const C& c) -> decltype(c.size()) {
  return static_cast<std::size_t>(c.size());
}

constexpr std::size_t size(const char* string) {
  std::size_t size = 0;
  while (*(string + size) != '\0') {
    ++size;
  }
  return size;
}

template<class T, std::size_t N>
constexpr std::size_t size(const T (&)[N]) noexcept {
  return N;
}
}

template<typename... Args>
std::string concatStrings(Args&&... args) {
  auto s = (size(args) + ...);
  std::string result;
  result.reserve(s);
  return (result.append(std::forward<Args>(args)), ...);
}