last day (15 days later) » 

13:14
14
A: Parser written in PHP is 5.6x faster than the same C++ program in a similar test (g++ 4.8.5)

EdwardThere are a number of things you can do to improve your code. Use const references where practical The parameters passed to the functions can be sped up by passing them as const references instead of by value. Doing so tells both the compiler and other readers of the code that the passed paramet...

What about the php times?
@MartinYork: I don't know. I try running it and get an error: Undefined offset: 3 in foo.php on line 9. I don't do much PHP and haven't figured out how to fix it yet.
Updated mine (with a minor tweak for speed) :-)
@MartinYork Updated timing (with your tweak included) and added PHP timing with fixed PHP code.
Darn php is quicker than I suspected.
13:14
It surprised me as well. Not 5.6x faster, but competitively fast with a very simple program. And that's why we time things! :)
It should not be surprising at all that PHP does so well here. The time is going to be I/O-bound, not dictated by the programming language.
My results are: (Xcode, clang 10 -Ofast): Akki, fmt::print(FILE, "{}..", vec[0]..): 4.2, 4.1, 4.2, Edward code as given: 4.8s, 4.6s, 4.9s. Code for Akki: ideone.com/siFp3A Also, the time spent in the writer (fmt::print) is ~400ms and for writeLine is ~700ms. But that is not a major dent in the 4 seconds taken by the rest of the code. CC @MartinYork
@akki: Thanks for sharing measurements. What machine and OS?
macOS Mojave, MacBook Air.
@akki: may I incorporate your timings into my answer?
13:14
Sure! :) If you could give me the code you used under my name, I can give one more data point.
Here it is: ideone.com/5ivw9R Please let me know if I've made any errors in interpretation. What I attempted to do was to write essentially the same version using the fprintf approach you described and the notionally equivalent iostream version.
I checked the two codes: ideone.com/5ivw9R this is the straightforward, naive way that I would've written. 5.6, 5.7, 5.7. ideone.com/0Lmr5P this is what you wrote, but streams have been replaced with fprintf. : 4.8, 4.6, 4.7. So within error limits and at par with streams I'd say. I edited that into my answer already. // Nice design you two came up with!
Change: splitLine.push_back(buf); to splitLine.emplace_back(std::move(buf));
I can't help to notice that while you have an early exit while parsing in C++ you still have php parse the whole line. Similarly, while C++ just outputs the needed fields, php is creating a data structure and then pass that to a library function to concatenate it into a new string variable, which is then output. Shouldn't the two programs be implementations of the same algorithm?
@Rad80 This went into the territory of optimisation strategies from a comparison with php, since the former is more interesting. "Shouldn't the two programs be implementations of the same algorithm" If OP is looking for the fastest parser we're here to help with C++ code. Someone more experienced in php is welcome to post an optimised php code. As Edward said above, he's not proficient in php.
Edward: Just fyi ideone.com/3IogGE here's a code with 2.7s on my machine in continuation to the other timings I reported yesterday. It's the fastest so far & the bottleneck is fileIO getline now with 64% of the time.16% splitting & 11% writing.
13:14
O man. The battle is on!
Updated to use string_view (though I can't store a vector of string_view as that would make the iterator non copyable). Instead I store a vector of int so I can build a string view on demand. That should half the speed of the application.
@MartinYork: timing chart updated.
@Edward Well that's slightly surprising. I was expecting "Matthew's" code to still be faster.
@Edward @Edward thanks! I could get it to work and added the timings to my answer.

last day (15 days later) »