การใช้ scanf () ในโปรแกรม C ++ จะเร็วกว่าการใช้ cin?

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

ตรวจสอบวิธีอินพุต / เอาต์พุตของคุณ ใน C ++ การใช้ cin และ cout ช้าเกินไป ใช้สิ่งเหล่านี้และคุณจะรับประกันว่าจะไม่สามารถแก้ไขปัญหาใด ๆ ด้วยอินพุตหรือเอาต์พุตในปริมาณที่เหมาะสม ใช้ printf และ scanf แทน

ใครช่วยชี้แจงเรื่องนี้ได้ไหม การใช้scanf ()ในโปรแกรม C ++ เร็วกว่าการใช้cin >> บางอย่างหรือไม่? ถ้าใช่การใช้งานในโปรแกรม C ++ เป็นวิธีปฏิบัติที่ดีหรือไม่? ฉันคิดว่ามันเป็นภาษา C เฉพาะแม้ว่าฉันจะเพิ่งเรียนรู้ C ++ ...

นี่คือการทดสอบอย่างรวดเร็วของกรณีง่ายๆ: โปรแกรมอ่านรายการตัวเลขจากอินพุตมาตรฐานและ XOR ตัวเลขทั้งหมด

เวอร์ชัน iostream:

#include <iostream>

int main(int argc, char **argv) {

  int parity = 0;
  int x;

  while (std::cin >> x)
    parity ^= x;
  std::cout << parity << std::endl;

  return 0;
}

scanf รุ่น:

#include <stdio.h>

int main(int argc, char **argv) {

  int parity = 0;
  int x;

  while (1 == scanf("%d", &x))
    parity ^= x;
  printf("%d\n", parity);

  return 0;
}

ผล

ด้วยโปรแกรมที่สามฉันสร้างไฟล์ข้อความที่มีตัวเลขสุ่ม 33,280,276 เวลาดำเนินการคือ:

iostream version:  24.3 seconds
scanf version:      6.4 seconds

การเปลี่ยนการตั้งค่าการเพิ่มประสิทธิภาพของคอมไพเลอร์ดูเหมือนจะไม่ทำให้ผลลัพธ์เปลี่ยนแปลงไปมากนัก

ดังนั้น: มีความแตกต่างของความเร็วจริงๆ

แก้ไข:ผู้ใช้ clyfish ชี้ให้เห็นด้านล่างว่าความแตกต่างของความเร็วส่วนใหญ่เกิดจากฟังก์ชัน iostream I / O ที่รักษาการซิงโครไนซ์กับฟังก์ชัน CI / O เราสามารถปิดสิ่งนี้ได้โดยโทรไปที่std::ios::sync_with_stdio(false);:

#include <iostream>

int main(int argc, char **argv) {

  int parity = 0;
  int x;

  std::ios::sync_with_stdio(false);

  while (std::cin >> x)
    parity ^= x;
  std::cout << parity << std::endl;

  return 0;
}

ผลลัพธ์ใหม่:

iostream version:                       21.9 seconds
scanf version:                           6.8 seconds
iostream with sync_with_stdio(false):    5.5 seconds

C ++ iostream ชนะ! ปรากฎว่าการซิงค์ / ล้างข้อมูลภายในเป็นสิ่งที่ทำให้ iostream i / o ทำงานช้าลง ถ้าเราไม่ผสม stdio กับ iostream เราสามารถปิดได้แล้ว iostream จะเร็วที่สุด

รหัส: https://gist.github.com/3845568

http://www.quora.com/Is-cin-cout-slower-than-scanf-printf/answer/Aditya-Vishwakarma

ประสิทธิภาพของcin/ coutอาจช้าเนื่องจากจำเป็นต้องซิงค์ตัวเองกับไลบรารี C ที่อยู่เบื้องหลัง นี่เป็นสิ่งสำคัญหากจะใช้ทั้ง C IO และ C ++ IO

อย่างไรก็ตามหากคุณจะใช้ C ++ IO เพียงแค่ใช้บรรทัดด้านล่างก่อนการดำเนินการ IO ใด ๆ

std::ios::sync_with_stdio(false);

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้โปรดดูที่เอกสาร libstdc ++ ที่เกี่ยวข้อง

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

มีบทความที่น่าอร่อยมากที่เขียนโดย Herb Sutter " The String Formatters of Manor Farm " ซึ่งให้รายละเอียดมากมายเกี่ยวกับประสิทธิภาพของการจัดรูปแบบสตริงเช่นsscanfและlexical_castประเภทของสิ่งที่ทำให้มันทำงานช้าหรือเร็ว นี่เป็นสิ่งที่คล้ายคลึงกันซึ่งอาจเป็นสิ่งที่จะส่งผลต่อประสิทธิภาพระหว่างสไตล์ C IO และสไตล์ C ++ ความแตกต่างหลักกับรูปแบบมักจะเป็นความปลอดภัยของประเภทและจำนวนการจัดสรรหน่วยความจำ

ฉันเพิ่งใช้เวลาช่วงเย็นในการแก้ปัญหาบน UVa Online (Factovisors เป็นปัญหาที่น่าสนใจมากลองดูสิ):

http://uva.onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8&category=35&page=show_problem&problem=1080

ฉันได้รับ TLE (เกินขีด จำกัด เวลา) ในการส่งของฉัน ในการแก้ปัญหาเว็บไซต์ตัดสินออนไลน์เหล่านี้คุณมีเวลาประมาณ 2-3 วินาทีในการจัดการกรณีทดสอบหลายพันกรณีที่อาจใช้ในการประเมินโซลูชันของคุณ สำหรับปัญหาที่ต้องใช้การคำนวณอย่างหนักเช่นนี้ทุกๆไมโครวินาทีจะมีค่า

ฉันใช้อัลกอริทึมที่แนะนำ (อ่านเกี่ยวกับในฟอรัมสนทนาของไซต์) แต่ยังคงได้รับ TLE

ฉันเปลี่ยนแค่ "cin >> n >> m" เป็น "scanf ("% d% d ", & n, & m)" และ "couts" เล็ก ๆ น้อย ๆ เป็น "printfs" และ TLE ของฉันก็เปลี่ยนเป็น "ยอมรับแล้ว"!

ใช่มันสามารถสร้างความแตกต่างได้มากโดยเฉพาะอย่างยิ่งเมื่อเวลาที่ จำกัด สั้น

หากคุณสนใจทั้งประสิทธิภาพและการจัดรูปแบบสตริงลองดูที่ไลบรารีFastFormat ของ Matthew Wilson

แก้ไข - ลิงก์ไปยังสิ่งพิมพ์ของ Accu ในไลบรารีนั้น: http://accu.org/index.php/journals/1539

มีการใช้งาน stdio ( libio ) ซึ่งใช้ FILE * เป็น C ++ streambuf และ fprintf เป็นตัวแยกวิเคราะห์รูปแบบรันไทม์ IOstreams ไม่จำเป็นต้องแยกวิเคราะห์รูปแบบรันไทม์ซึ่งทำได้ทั้งหมดในเวลาคอมไพล์ ดังนั้นด้วยแบ็กเอนด์ที่ใช้ร่วมกันจึงสมเหตุสมผลที่จะคาดหวังว่า iostreams จะเร็วกว่าในขณะรันไทม์

ใช่ iostream ช้ากว่า cstdio
ใช่คุณอาจไม่ควรใช้ cstdio หากคุณกำลังพัฒนาใน C ++
ต้องบอกว่ามีวิธีที่เร็วกว่าในการรับ I / O มากกว่า scanf หากคุณไม่สนใจเกี่ยวกับการจัดรูปแบบประเภทความปลอดภัย blah blah blah ...

ตัวอย่างเช่นนี่เป็นกิจวัตรที่กำหนดเองเพื่อรับหมายเลขจาก STDIN:

inline int get_number()
{
    int c;        
    int n = 0;

    while ((c = getchar_unlocked()) >= '0' && c <= '9')
    {
        // n = 10 * n + (c - '0');
        n = (n << 3) + ( n << 1 ) + c - '0';
    }
    return n;
}

ข้อความcinและcoutการใช้งานทั่วไปดูเหมือนจะช้ากว่าscanfและprintfใน C ++ แต่จริงๆแล้วมันเร็วกว่า!

สิ่งนี้คือ: ใน C ++ เมื่อใดก็ตามที่คุณใช้cinและcoutกระบวนการซิงโครไนซ์จะเกิดขึ้นตามค่าเริ่มต้นซึ่งทำให้แน่ใจว่าหากคุณใช้ทั้งสองอย่างscanfและcinในโปรแกรมของคุณทั้งสองจะทำงานโดยซิงค์กัน กระบวนการซิงค์นี้ต้องใช้เวลา ดังนั้นcinและcoutดูเหมือนจะช้าลง

แต่ถ้าการประสานการตั้งค่าเพื่อไม่ให้เกิดขึ้นเร็วกว่าcinscanf

หากต้องการข้ามขั้นตอนการซิงค์ให้ใส่ข้อมูลโค้ดต่อไปนี้ในโปรแกรมของคุณที่จุดเริ่มต้นของmain():

std::ios::sync_with_stdio(false);

เยี่ยมชมไซต์นี้เพื่อดูข้อมูลเพิ่มเติม

ปัญหาคือcinมีค่าใช้จ่ายจำนวนมากที่เกี่ยวข้องเพราะมันทำให้คุณมีเลเยอร์นามธรรมเหนือการscanf()โทร คุณไม่ควรใช้scanf()มากกว่าcinถ้าคุณเขียนซอฟแวร์ c ++ เพราะเห็นว่าเป็นความต้องการของคุณcinเป็น หากคุณต้องการประสิทธิภาพคุณอาจจะไม่ได้เขียน I / O ใน C ++

#include <stdio.h>
#include <unistd.h>

#define likely(x)       __builtin_expect(!!(x), 1)
#define unlikely(x)     __builtin_expect(!!(x), 0)

static int scanuint(unsigned int* x)
{
  char c;
  *x = 0;

  do
  {
      c = getchar_unlocked();
      if (unlikely(c==EOF)) return 1;
  } while(c<'0' || c>'9');

  do
  {
      //*x = (*x<<3)+(*x<<1) + c - '0';
      *x = 10 * (*x) + c - '0';
      c = getchar_unlocked();
      if (unlikely(c==EOF)) return 1;
  } while ((c>='0' && c<='9'));

  return 0;
}

int main(int argc, char **argv) {

  int parity = 0;
  unsigned int x;

  while (1 != (scanuint(&x))) {
    parity ^= x;
  }
  parity ^=x;
  printf("%d\n", parity);

  return 0;
}

มีจุดบกพร่องที่ท้ายไฟล์ แต่รหัส C นี้เร็วกว่ารุ่น C ++ ที่เร็วกว่ามาก

paradox@scorpion 3845568-78602a3f95902f3f3ac63b6beecaa9719e28a6d6 ▶ make test        
time ./xor-c < rand.txt
360589110

real    0m11,336s
user    0m11,157s
sys 0m0,179s
time ./xor2-c < rand.txt
360589110

real    0m2,104s
user    0m1,959s
sys 0m0,144s
time ./xor-cpp < rand.txt
360589110

real    0m29,948s
user    0m29,809s
sys 0m0,140s
time ./xor-cpp-noflush < rand.txt
360589110

real    0m7,604s
user    0m7,480s
sys 0m0,123s

C ++ ดั้งเดิมใช้เวลา 30 วินาทีรหัส C ใช้เวลา 2 วินาที

แน่นอนว่ามันไร้สาระที่จะใช้ cstdio กับ iostream อย่างน้อยที่สุดเมื่อคุณพัฒนาซอฟต์แวร์ (หากคุณใช้ c ++ มากกว่า c อยู่แล้วให้ทำทุกวิถีทางและใช้ประโยชน์ของมันแทนที่จะต้องทนทุกข์ทรมานจากข้อเสียเท่านั้น)

แต่ในการตัดสินออนไลน์คุณไม่ได้พัฒนาซอฟต์แวร์คุณกำลังสร้างโปรแกรมที่ควรจะทำสิ่งต่างๆซอฟต์แวร์ Microsoft ใช้เวลา 60 วินาทีเพื่อให้บรรลุใน 3 วินาที !!!

ดังนั้นในกรณีนี้กฎทองก็เป็นเช่นนั้น (แน่นอนว่าถ้าคุณไม่ได้รับปัญหามากขึ้นโดยใช้ java)

• ใช้ c ++ และใช้พลังทั้งหมด (และความหนัก / ความช้า) ในการแก้ปัญหา
• หากคุณมีเวลา จำกัด ให้เปลี่ยน cins และ couts สำหรับ printfs และ scanfs (ถ้าคุณเมาโดยใช้ class string ให้พิมพ์ดังนี้ printf (% s, mystr.c_str ());
• หากคุณยังมีเวลา จำกัด ให้พยายามเพิ่มประสิทธิภาพที่ชัดเจน (เช่นหลีกเลี่ยงการฝังตัวมากเกินไปสำหรับ / while / dowhiles หรือฟังก์ชันวนซ้ำ) ตรวจสอบให้แน่ใจว่าได้ส่งผ่านวัตถุอ้างอิงที่ใหญ่เกินไป ...
• หากคุณยังมีเวลา จำกัด ลองเปลี่ยน std :: vectors และชุดสำหรับ c-arrays
• หากคุณยังมีเวลา จำกัด ให้ไปที่ปัญหาต่อไป ...

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