python read - 為什麼讀取stdin中的行比C++慢得多?




file fstream (9)

那麼,我發現在你的第二個解決方案中,你從cin切換到scanf ,這是我準備給你的第一個建議(cin is sloooooooooooow)。 現在,如果你從scanf切換到fgets ,你會看到性能的另一個提升: fgets是字符串輸入最快的C ++函數。

順便說一句,不知道那個同步的事情,很好。 但你仍然應該嘗試fgets

我想比較使用Python和C ++的stdin字符串輸入的讀取行,並且很驚訝地發現我的C ++代碼比等效的Python代碼慢了一個數量級。 由於我的C ++很生疏,而且我還不是專家蟒蛇,所以請告訴我,如果我做錯了什麼或者我誤解了某些東西。

(TLDR答案:包括聲明: cin.sync_with_stdio(false)或者只是使用fgets代替。

TLDR結果:一直滾動到我的問題的底部並查看表格。)

C ++代碼:

#include <iostream>
#include <time.h>

using namespace std;

int main() {
    string input_line;
    long line_count = 0;
    time_t start = time(NULL);
    int sec;
    int lps;

    while (cin) {
        getline(cin, input_line);
        if (!cin.eof())
            line_count++;
    };

    sec = (int) time(NULL) - start;
    cerr << "Read " << line_count << " lines in " << sec << " seconds.";
    if (sec > 0) {
        lps = line_count / sec;
        cerr << " LPS: " << lps << endl;
    } else
        cerr << endl;
    return 0;
}

// Compiled with:
// g++ -O3 -o readline_test_cpp foo.cpp

Python等效:

#!/usr/bin/env python
import time
import sys

count = 0
start = time.time()

for line in  sys.stdin:
    count += 1

delta_sec = int(time.time() - start_time)
if delta_sec >= 0:
    lines_per_sec = int(round(count/delta_sec))
    print("Read {0} lines in {1} seconds. LPS: {2}".format(count, delta_sec,
       lines_per_sec))

這是我的結果:

$ cat test_lines | ./readline_test_cpp
Read 5570000 lines in 9 seconds. LPS: 618889

$cat test_lines | ./readline_test.py
Read 5570000 lines in 1 seconds. LPS: 5570000

編輯: 我應該注意到,我在Mac OS X v10.6.8(Snow Leopard)和Linux 2.6.32(Red Hat Linux 6.2)下都嘗試了這一點。 前者是一台MacBook Pro,後者則是一台非常強大的服務器,並不是說這樣太貼切。

編輯2 :( 刪除此編輯,不再適用)

$ for i in {1..5}; do echo "Test run $i at `date`"; echo -n "CPP:"; cat test_lines | ./readline_test_cpp ; echo -n "Python:"; cat test_lines | ./readline_test.py ; done
Test run 1 at Mon Feb 20 21:29:28 EST 2012
CPP:   Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 2 at Mon Feb 20 21:29:39 EST 2012
CPP:   Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 3 at Mon Feb 20 21:29:50 EST 2012
CPP:   Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 4 at Mon Feb 20 21:30:01 EST 2012
CPP:   Read 5570001 lines in 9 seconds. LPS: 618889
Python:Read 5570000 lines in 1 seconds. LPS: 5570000
Test run 5 at Mon Feb 20 21:30:11 EST 2012
CPP:   Read 5570001 lines in 10 seconds. LPS: 557000
Python:Read 5570000 lines in  1 seconds. LPS: 5570000

編輯3:

好的,我嘗試了JN的建議,試圖讓Python存儲行讀取:但它對python的速度沒有任何影響。

我也嘗試了JN的建議, scanf轉換為char數組,而不是將getline轉換為std::string 。 答對了! 這導致Python和C ++的性能相當。 (我的輸入數據是3,333,333個LPS,順便說一句,每個都只有三個字段的短行,通常約20個字符寬,有時甚至更多)。

碼:

char input_a[512];
char input_b[32];
char input_c[512];
while(scanf("%s %s %s\n", input_a, input_b, input_c) != EOF) {
    line_count++;
};

速度:

$ cat test_lines | ./readline_test_cpp2
Read 10000000 lines in 3 seconds. LPS: 3333333
$ cat test_lines | ./readline_test2.py
Read 10000000 lines in 3 seconds. LPS: 3333333

(是的,我跑了幾次。)所以,我想我現在將使用scanf而不是getline 。 但是,如果人們認為std::string / getline這種性能是典型和合理的,我仍然很好奇。

編輯4(是:最終編輯/解決方案):

添加:

cin.sync_with_stdio(false);

在我上面的原始while循環之上立即產生比Python運行得更快的代碼。

新的性能比較 (這是在我的2011年MacBook Pro上),分別使用原始代碼,禁用同步的原始代碼和原始Python代碼,在具有20M行文本的文件上進行比較。 是的,我跑了幾次,以消除磁盤緩存混淆。

$ /usr/bin/time cat test_lines_double | ./readline_test_cpp
       33.30 real         0.04 user         0.74 sys
Read 20000001 lines in 33 seconds. LPS: 606060
$ /usr/bin/time cat test_lines_double | ./readline_test_cpp1b
        3.79 real         0.01 user         0.50 sys
Read 20000000 lines in 4 seconds. LPS: 5000000
$ /usr/bin/time cat test_lines_double | ./readline_test.py
        6.88 real         0.01 user         0.38 sys
Read 20000000 lines in 6 seconds. LPS: 3333333

感謝@Vaughn Cato的回答! 任何精心製作的人們都可以做出很好的引用,人們可以指出為什麼這種同步發生,它的意思,什麼時候有用,什麼時候可以禁用,將會被後人所高度讚賞。 :-)

編輯5 /更好的解決方案:

正如Gandalf The Gray所建議的那樣, scanfscanf或非同步cin方法更快。 我還了解到scanfgets都是不安全的,並且由於潛在的緩衝區溢出而不應該被使用。 所以,我用fgets寫了這個迭代,這是獲得更安全的選擇。 下面是我的同伴新手的相關內容:

char input_line[MAX_LINE];
char *result;

//<snip>

while((result = fgets(input_line, MAX_LINE, stdin )) != NULL)
    line_count++;
if (ferror(stdin))
    perror("Error reading stdin.");

現在,下面是在具有非常快的磁盤的快速服務器上使用更大文件(100M行;〜3.4 GB)的結果,比較Python代碼,非同步cinfgets方法,以及與wc實用程序進行比較。 [ scanf版本分割錯誤,我不想排除故障。]:

$ /usr/bin/time cat temp_big_file | readline_test.py
0.03user 2.04system 0:28.06elapsed 7%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
Read 100000000 lines in 28 seconds. LPS: 3571428

$ /usr/bin/time cat temp_big_file | readline_test_unsync_cin
0.03user 1.64system 0:08.10elapsed 20%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
Read 100000000 lines in 8 seconds. LPS: 12500000

$ /usr/bin/time cat temp_big_file | readline_test_fgets
0.00user 0.93system 0:07.01elapsed 13%CPU (0avgtext+0avgdata 2448maxresident)k
0inputs+0outputs (0major+181minor)pagefaults 0swaps
Read 100000000 lines in 7 seconds. LPS: 14285714

$ /usr/bin/time cat temp_big_file | wc -l
0.01user 1.34system 0:01.83elapsed 74%CPU (0avgtext+0avgdata 2464maxresident)k
0inputs+0outputs (0major+182minor)pagefaults 0swaps
100000000


Recap (lines per second):
python:         3,571,428
cin (no sync): 12,500,000
fgets:         14,285,714
wc:            54,644,808

正如你所看到的, fgets比較好,但離wc性能還差得很遠; 我很確定這是由於wc檢查每個字符而沒有任何內存複製的事實。 我懷疑在這一點上,代碼的其他部分將成為瓶頸,所以即使可能的話,我也不認為優化到這個水平甚至是值得的(因為畢竟我實際上需要存儲讀取線在記憶中)。

還要注意,使用char *緩衝區和fgets與非同步cin進行字符串的小折衷是,後者可以讀取任意長度的行,而前者要求將輸入限制為某個有限數字。 在實踐中,讀取大多數基於行的輸入文件可能不是問題,因為緩衝區可以設置為非常大的值,而不會被有效輸入超出。

這是教育。 感謝大家的意見和建議。

編輯6:

正如JF Sebastian在下面的評論中所建議的那樣,GNU wc實用程序使用plain C read() (在safe-read.c包裝器中)每次讀取16k字節的塊併計算新行。 下面是一個基於JF代碼的Python等價物(只顯示替代Python for循環的相關代碼片段:

BUFFER_SIZE = 16384
count = sum(chunk.count('\n') for chunk in iter(partial(sys.stdin.read, BUFFER_SIZE), ''))

這個版本的性能非常快(當然,仍然比原始的C wc工具慢):

$ /usr/bin/time cat temp_big_file | readline_test3.py
0.01user 1.16system 0:04.74elapsed 24%CPU (0avgtext+0avgdata 2448maxresident)k
0inputs+0outputs (0major+181minor)pagefaults 0swaps
Read 100000000 lines in 4.7275 seconds. LPS: 21152829

同樣,對於我來說,將C ++ fgets / cin和第一個Python代碼與wc -l以及另一個Python代碼片段進行比較對我來說有點愚蠢,因為後兩者實際上並不存儲讀取的行,但是只需要換行符。 不過,探索所有不同的實現並考慮性能影響很有意思。 再次感謝!

編輯7:微小的基準附錄和回顧

為了完整起見,我認為我會用原始(同步的)C ++代碼更新同一個文件夾中相同文件的讀取速度。 再次,這是一個快速磁盤上的100M行文件。 這裡是完整的表格:

Implementation      Lines per second
python (default)           3,571,428
cin (default/naive)          819,672
cin (no sync)             12,500,000
fgets                     14,285,714
wc (not fair comparison)  54,644,808

我在Mac上使用g ++在計算機上複製了原始結果。

while循環之前將以下語句添加到C ++版本,使其與Python版本內聯:

std::ios_base::sync_with_stdio(false);
char buffer[1048576];
std::cin.rdbuf()->pubsetbuf(buffer, sizeof(buffer));

sync_with_stdio將速度提高到2秒,並將較大的緩衝區設置為1秒。


我在這裡落後了幾年,但是:

在原文的“編輯4/5/6”中,您使用的是建築物:

$ /usr/bin/time cat big_file | program_to_benchmark

這在幾個不同的方面是錯誤的:

  1. 你實際上計算`cat`的執行時間,而不是你的基準。 `time'顯示的'user'和'sys'CPU使用率是`cat`的,而不是基準程序。 更糟糕的是,“真實”時間也不一定準確。 根據你本地操作系統中`cat`和管道的實現情況,`cat`可能會寫入一個最終的巨大緩衝區,並在讀者程序結束之前就退出。

  2. 使用“貓”是不必要的,事實上也適得其反。 你正在添加移動部件。 如果你使用的是足夠舊的系統(即只有一個CPU,並且 - 在某些代計算機中--I / O比CPU更快) - “貓”運行的事實可能會大大增加結果的顏色。 你也受到任何輸入和輸出緩衝以及`cat`可能做的其他處理的支配。 (如果我是蘭德爾施瓦茨,這可能會讓你獲得'無用的貓'獎: https://en.wikipedia.org/wiki/Cat_(Unix)#UUOC_(Useless_Use_Of_Cat) ://en.wikipedia.org/wiki/Cat_(Unix https://en.wikipedia.org/wiki/Cat_(Unix)#UUOC_(Useless_Use_Of_Cat) #UUOC_(Useless_Use_Of_Cat https://en.wikipedia.org/wiki/Cat_(Unix)#UUOC_(Useless_Use_Of_Cat)

更好的構造是:

$ /usr/bin/time program_to_benchmark < big_file

在這個聲明中,它是打開big_file的shell ,將它傳遞給你的程序(實際上是'time',然後執行你的程序作為一個子進程)作為一個已經打開的文件描述符。 文件閱讀的100%完全是你正在嘗試進行基準測試的程序的責任。 這可以讓您真正了解其性能,而不會產生虛假複雜情況。

我會提到兩個可能的,但實際上是錯誤的,也可以考慮的“修復”(但我對它們的編號是不同的,因為它們不是原始文章中錯誤的):

答:你可以通過只計算你的程序來“解決”這個問題:

$ cat big_file | /usr/bin/time program_to_benchmark

B.或通過對整個管線進行計時:

$ /usr/bin/time sh -c 'cat big_file | program_to_benchmark'

由於與#2相同的原因,這些都是錯誤的:他們仍在不必要地使用“貓”。 我提到他們有幾個原因:

  • 對於那些不熟悉POSIX shell的I / O重定向功能的人來說,它們更“自然”

  • 可能會出現需要`cat` 情況(例如:要讀取的文件需要某種特權才能訪問,而且您不希望將該特權授予要進行基準測試的程序:`sudo cat / dev / sda | / usr / bin / time my_compression_test --no-output`)

  • 在實踐中 ,在現代化的機器上,管道中增加的“貓”可能沒有真正的結果

但是我有些猶豫地說最後一件事。 如果我們檢查'編輯5'中的最後一個結果 -

$ /usr/bin/time cat temp_big_file | wc -l
0.01user 1.34system 0:01.83elapsed 74%CPU ...

- 這聲稱在測試過程中`cat`消耗了74%的CPU; 事實上1.34 / 1.83約為74%。 也許是一連串的:

$ /usr/bin/time wc -l < temp_big_file

本來只需要剩下的49秒! 可能不是:`貓`在這裡必須支付read()系統調用(或等價物),它將文件從“磁盤”(實際上是緩衝區緩存)中轉移出來,以及管道寫入將它們傳遞給`wc`。 正確的測試仍然必須執行read()調用; 只有寫入管道和管道讀取會被保存,而且這些應該相當便宜。

不過,我預測你可以測量`cat file |之間的差異 wc -l`和`wc -l <​​file`,並找到明顯的(2位百分比)差異。 每個較慢的測試都會在絕對時間內支付類似的懲罰; 這將佔其較大總時間的一小部分。

事實上,我在Linux 3.13(Ubuntu 14.04)系統上用1.5 GB的垃圾文件做了一些快速測試,獲得了這些結果(當然,這些結果實際上是'3中最好的結果;在啟動緩存之後):

$ time wc -l < /tmp/junk
real 0.280s user 0.156s sys 0.124s (total cpu 0.280s)
$ time cat /tmp/junk | wc -l
real 0.407s user 0.157s sys 0.618s (total cpu 0.775s)
$ time sh -c 'cat /tmp/junk | wc -l'
real 0.411s user 0.118s sys 0.660s (total cpu 0.778s)

請注意,這兩個管道結果聲稱佔用了比實時更多的CPU時間(用戶+ sys)。 這是因為我正在使用shell(Bash)的內置“時間”命令,這是對管道的認識; 而且我在多核機器上,管道中的單獨進程可以使用不同的核心,因此CPU時間比實時更快。 使用/ usr / bin / time我看到的CPU時間比實時更短 - 表明它只能對在其命令行上傳遞給它的單個管道元素計時。 另外,shell的輸出會給出毫秒數,而/ usr / bin / time只能給出秒數的結果。

因此,在`wc -l`的效率水平上,`cat`會產生巨大的差異:409/283 = 1.453或45.3%的實時性,775/280 = 2.768,或者使用的CPU超過177%! 在我的隨機它是在那裡的時間測試盒。

我應該補充說,這些測試方式之間至少存在一個其他顯著差異,我不能說這是否是一種好處或缺點; 你必須自己決定:

當你運行`cat big_file | / usr / bin / time my_program`,你的程序正在接收來自管道的輸入,正好以`cat`發送的速度,並且不大於`cat`寫入的區塊。

當你運行`/ usr / bin / time my_program <big_file`時,你的程序會收到一個打開的文件描述符給實際的文件。 您的程序 - 或者在很多情況下,其寫入語言的I / O庫 - 在提供引用常規文件的文件描述符時可能會採取不同的操作。 它可以使用mmap(2)將輸入文件映射到其地址空間,而不是使用顯式讀取(2)系統調用。 這些差異對基準測試結果的影響可能比運行`cat`二進製文件的小成本要大得多。

當然這是一個有趣的基準測試結果,如果同一個程序在兩種情況下表現差異很大。 它表明,確實,程序或其I / O庫正在做一些有趣的事情,比如使用mmap()。 所以在實踐中,兩種方式都可以運行基準。 也許可以通過一些小因素來折扣“貓”結果,以“原諒”運行“貓”本身的成本。


答案的第一個元素: <iostream>很慢。 該死的很慢。 如下所示,我用scanf獲得了巨大的性能提升,但仍然比Python慢​​兩倍。

#include <iostream>
#include <time.h>
#include <cstdio>

using namespace std;

int main() {
    char buffer[10000];
    long line_count = 0;
    time_t start = time(NULL);
    int sec;
    int lps;

    int read = 1;
    while(read > 0) {
        read = scanf("%s", buffer);
        line_count++;
    };
    sec = (int) time(NULL) - start;
    line_count--;
    cerr << "Saw " << line_count << " lines in " << sec << " seconds." ;
    if (sec > 0) {
        lps = line_count / sec;
        cerr << "  Crunch speed: " << lps << endl;
    } 
    else
        cerr << endl;
    return 0;
}

出於好奇,我看了一下發生了什麼,我在每次測試中都使用了dtruss/strace

C ++

./a.out < in
Saw 6512403 lines in 8 seconds.  Crunch speed: 814050

syscalls sudo dtruss -c ./a.out < in

CALL                                        COUNT
__mac_syscall                                   1
<snip>
open                                            6
pread                                           8
mprotect                                       17
mmap                                           22
stat64                                         30
read_nocancel                               25958

蟒蛇

./a.py < in
Read 6512402 lines in 1 seconds. LPS: 6512402

syscalls sudo dtruss -c ./a.py < in

CALL                                        COUNT
__mac_syscall                                   1
<snip>
open                                            5
pread                                           8
mprotect                                       17
mmap                                           21
stat64                                         29

如果您不關心文件加載時間或者您正在加載小文本文件, getline ,流操作符scanf可以很方便。 但是,如果性能是你關心的,那麼你應該將整個文件緩衝到內存中(假設它適合)。

這是一個例子:

//open file in binary mode
std::fstream file( filename, std::ios::in|::std::ios::binary );
if( !file ) return NULL;

//read the size...
file.seekg(0, std::ios::end);
size_t length = (size_t)file.tellg();
file.seekg(0, std::ios::beg);

//read into memory buffer, then close it.
char *filebuf = new char[length+1];
file.read(filebuf, length);
filebuf[length] = '\0'; //make it null-terminated
file.close();

如果你願意,你可以圍繞緩衝區打包一個流,以便更方便地訪問,如下所示:

std::istrstream header(&buffer[0], length);

另外,如果您在控製文件,請考慮使用平面二進制數據格式而不是文本。 讀取和寫入更可靠,因為您不必處理空白的所有含糊之處。 分析也更小,速度更快。


順便說一下,C ++版本的行數大於Python版本的行數的原因在於,只有在嘗試讀取超出eof時才會設置eof標誌。 所以正確的循環將是:

while (cin) {
    getline(cin, input_line);

    if (!cin.eof())
        line_count++;
};

在你的第二個例子(scanf())中,為什麼這個速度還是比較慢,可能是因為scanf(“%s”)分析字符串並查找任何空格字符(空格,製表符,換行符)。

另外,是的,CPython會執行一些緩存來避免硬盤讀取。


n = int(raw_input())
for i in xrange(n):
    name, number = raw_input().split()




c++ python benchmarking readline getline