Alternatywne cin/cout jest wolne?

Question

Na początek robię std::ios_base::sync_with_stdio(false). Mam następujące fragmenty kodu, czytanie milion liczby całkowite z pliku tekstowego (<input.txt >output.txt):

int tests; 
cin >> tests; 
for (int i = 0; i < tests; ++i) { 
    int number; 
    cin >> number; 
    cout << number << "\n"; 
} 

i

int tests; 
cin >> tests; 
vector<int> numbers(tests); 
for (int i = 0; i < tests; ++i) { 
    cin >> numbers[i]; 
} 
for (int i = 0; i < tests; ++i) { 
    cout << numbers[i] << "\n"; 
} 

Oczywiście, w rzeczywistości robią więcej niż tylko drukuje te same numery. Problem polega na tym, że pierwszy blok zajmuje około 4 razy więcej czasu (6,2 sekundy w stosunku do 1,8).

Przepisanie tego samego kodu z printf/scanf trwa 3 sekundy w obu przypadkach. Jaki jest tego powód?

Answer 1

Patrz std::basic_ios::tie, w szczególności te części:

Związany strumień jest strumień wyjściowy, który jest zsynchronizowany z sekwencją kontrolowanym buforem strumień (rdbuf()), to znaczy, flush() nazywa się od związanego strumień przed każdą operacją wejścia/wyjścia na *this.

Domyślnie standardowe strumienie cin, cerr i clog są powiązane z cout. Podobnie, ich szerokie odpowiedniki wcin, wcerr i wclog są związane z wcout.

Chodzi o to, aby upewnić się, że w typowej interaktywny program robi takie rzeczy jak cout << "Enter something: "; cin >> something;, monit faktycznie pojawi się na ekranie zanim program czeka na dane.

Ale w twoim przypadku te dodatkowe wywołania flush() pokonają wszelkie buforowanie, jakie mogą wykonać strumienie, co powoduje obniżenie wydajności.

można przerwać krawata cin.tie(nullptr);