$ cat big_file | time myprogram ... /dev/stdin 9.18user 0.11system 0:09.32elapsed 99%CPU (0avgtext+0avgdata 6608maxresident)k 0inputs+8624outputs (0major+471minor)pagefaults 0swapsHmm... now it's fine. But now reading goes through std::ifstream not from std::cin. I checked my concern with google-perftools - and what I saw: nearly 50% has been spent by calling of std::getline(), here is the top10 functions by google-perftools:
908 41.6% 41.6% 908 41.6% gogo::BlacklistFilter::exists <<< WORK 340 15.6% 57.2% 357 16.4% _IO_getc 271 12.4% 69.6% 1095 50.2% std::getline 221 10.1% 79.7% 239 11.0% _IO_acquire_lock_fct 172 7.9% 87.6% 193 8.8% _IO_ungetc 54 2.5% 90.1% 287 13.2% __gnu_cxx::stdio_sync_filebuf::uflow 48 2.2% 92.3% 48 2.2% std::__once_callable 43 2.0% 94.3% 43 2.0% _IO_sputbackc 37 1.7% 96.0% 37 1.7% std::_Rb_tree_black_count <<< WORK 27 1.2% 97.2% 275 12.6% __gnu_cxx::stdio_sync_filebuf::underflowFantastic! Hardly 45% is work_code-related, the rest caused by std::getline. Strange distribution, especially _IO_acquire_lock_fct function. This name seems to be self-explained, so I easily found this method: ios_base::sync_with_stdio. So, putting
std::cin.sync_with_stdio(false);
tamed my program as well. CPU time returned back and I'm happy again.Note, this behavior doesn't related to -pthread or anything else compiler-key. It's just become 30 to 40 times slower when you reading from std::cin, no matter using std::getline or not.
Surely, that's not the potion what make all programs faster, but I'll keep this std::ios' weakness in mind.
No comments:
Post a Comment