4 ms·
Unfortunately the currently available solution (boost::optional) performs enough worse that the difference can be measured in a simple implementation of "wc -l"
by jepler 11y ago
Unfortunately the currently available solution (boost::optional) performs enough worse that the difference can be measured in a simple implementation of "wc -l". Consider the following code:
#include <iostream>
#include <string>
#include <boost/optional.hpp>
using namespace std;
using namespace boost;
optional<string> getline_(istream &st) {
std::string line;
if(getline(st, line)) return line;
return none;
}
int main() {
int lines = 0;
while(getline_(cin)) lines++;
cout << lines << "\n";
}
vs
using namespace std;
int main() {
int lines = 0;
string line;
while(getline(cin, line)) lines++;
cout << lines << "\n";
}
Run on an input file of 172,544 lines (the GPL-3 license repeated 256 times), the version using "optional" takes 400ms and performs 1,077,504(!) heap allocations, while the more standard version takes just 280ms and performs just 8 allocations.
Of course, "wc -l" (GNU) takes just 9ms, so clearly this isn't a great program either way--but it does serve to show that boost::optional can be a surprising performance sink compared to using a bool return value + out parameter.
(tests on debian jessie amd64, i5-3320M @ 2.6GHz, g++ 4.9 -O3, boost 1.55.0.2)
- mavam 11y ago+1 for Having Measured It. The basic getline interface removes heap pressure by reusing the same string over and over, even though semantically the optional<string> approach may look cleaner. Eric Niebler showed a while ago (I can't remember where) that this API lends itself perfectly to ranges, and can provide both a reasonable interface without sacrificing performance. IIRC, the API looked somewhat like this: for (auto& line : getline_range(cin)) f(line); // do something with line, e.g., parse. The semantics are: iterate over standard input until EOF or error and let the range keep (and reuse) the string internally while exposing it as const-reference by dereferencing.
- imron 11y agoThat's not the fault of optional though. It's because with the optional version you're creating (and destroying) a new string each iteration of the loop. Something like this (untested) should be much closer to the non-optional version: #include <iostream> #include <string> #include <boost/optional.hpp> using namespace std; using namespace boost; optional<string&> getline_(istream &st, string& line) { if(getline(st, line)) return line; return none; } int main() { int lines = 0; string line; line.reserve( 1024 ); //1024 should be long enough for any line while(getline_(cin, line )) lines++; cout << lines << "\n"; }
- yoklov 11y agoWhich more or less removes any benefit for using optional, unfortunately.
- deleted 11y ago[deleted]
- imron 11y agoYes for this case, but that's just because it's a bad example for comparing the performance of optional, because the code is doing things that have very different performance characteristics. There are plenty of other cases though where it is useful to use optional (e.g. instead of passing/returning a naked pointer which may or may not be null) and in those cases use of optional will have little/no overhead.
- deleted 11y ago[deleted]