Hacker News Reader

Comment by thethirdone | Hacker News Reader

If you look at part 1 [0], it is pretty clear that std::map is not THE major bottle neck. The whole program is pretty slow.

The issues I see are: a lot of string copying instead of string views, splitting strings into vectors rather than splitting on demand, replacing on the same string repeatedly and collecting into a string before adding it to another string. It seems like their benchmark data has a lot of small lines with set and value commands, which would not be majorly hurt by those issues.

The performance of ~20MB/s is REALLY SLOW for string processing in cpp. A fast but not super optimized c++ program should be getting in the ballpark of 500MB/s.

[0]: https://julien.jorge.st/posts/en/effortless-performance-impr...

View on HN

Clearly a veteran of C++ in particular or the “zero-cost abstraction” cluster of languages in general is not going to miss a bunch of needless allocations etc. in a setting where performance matters a lot and I basically agree about the high notes of where you’d start to tune this up.

But the author is clearly a highly-motivated intermediate C++ user who is taking time to share some key lessons and anyone who keeps that up for long won’t be intermediate for long!

So it’s still a cool blog IMHO :)

Well I'm always surprised how the actual implementation of the stl primitives looks like "C++ cool tricks 101" turned to eleven and I wouldn't be surprised if the ability of compilers to optimize that was not great

Eh, the folks writing the standard library definitely work adjacent to the folks doing the compiler in C++ for sure and I think Rust and stuff too. Both gcc and clang for example ship with co-designed standard libraries.

It’s backwards compatibility that kills them on performance which is why the 900-IQ C++ shops like Google etc. just go their own way on the hash table because it’s worth it to them to do the extra work.

It's not just backwards compat, it's all the crazy guarantees that the stdlib has to make. Most code doesn't have strong exception guarantees... the stdlib generally speaking does. It also has to deal with all sorts of silly things without breaking like people overloading operator,() and still expecting things to work without issue. They really are a case study in getting decent performance in most cases out of exceptionally defensively written code.

You have a lot of good points that will indeed be addressed in the next posts :)

The operations on the strings are subtly expensive and I was expecting to see them above the accesses to the maps in the perf report. Now they were not and I address the problems in the order of this report, so we will have to wait a bit to discuss them. The intent is also to unroll a scenario of optimization for the reader: measure to get insight, try something, measure again, decide.

If you have the time and the motivation I would love to see a fast but not super optimized version of this program. I tried to keep using the standard library and not going into cryptic code (i.e. trying to keep the code clear for an average programmer), and I stopped when the performance gain became very small, but I am pretty sure we can get better performance if we push further.

Going step by step, slowly tackling the issues while also showing the reason behind why it is optimized, is a great way to teach. Congrats on mentorship skills!

Their speedup from the initial code to the end of the map blogpost is ~5%. In their repo, they have a much better version that presumably there will eventually be blogposts leading up to. That version is approximately twice as fast as their initial version.

I worked on optimizing that version for a little while. The result is a version which takes 30% of the time of the original and a little worse than twice as fast as the best in the repo. That's still disappointingly slow to me, but I'm not great at c++ so I don't really want to take the time to try to improve it further.

Reply on news.ycombinator.com