Suggestion: Performance test iopipe with LDC's LTO and PGO support

[jondegenhardt]

Hi Steve,

I notice you been running some performance benchmarks on IOPipe. I saw material performance gains in my tools when I built them with LTO (Link time optimization), and further gains when adding PGO (Profile guided optimization). IOPipe apps might see some of the same benefits, might be worth giving it a try.

My results here: Silicon Valley D meetup slides, 14 Dec 2017. The PGO benchmarks were done after the talk, so they are not in the slides. The biggest source of benefits in my apps was likely better optimization of inlining, especially inlining of phobos/druntime code.

LTO is easy to setup, especially if you already have benchmark test code. PGO is mechanically easy, though there is more work to get reasonable profile data. I can provide more info on how I conducted my benchmarks if that would be helpful.

--Jon

[schveiguy]

Hi Jon, thanks for the tip. I did see your information posted on the forums, but haven't had a chance to read through it. Indeed, easy wins like this are easy wins for promoting D performance libraries such as iopipe or your tools.

The recent testing I'm doing I think might be a wild goose chase. I got iopipe to perform as well as C on my machine, but C performs better on someone else's. It could have nothing to do with iopipe's implementation, and simply how the data happens to be allocated by the allocator. Stuff like that is impossible to predict, and only shows up in micro benchmarks.

I'm still aiming to get back to porting tsv-utils to iopipe, but I feel iopipe is still too lacking in features to be pleasant enough of a transition :) At least now, though, you can depend on it with dub.

[jondegenhardt]

One detail not in the slides - The subsequent PGO tests included a pleasant surprise - the csv2tsv benchmark improved dramatically. That was one that always appeared unnecessarily slow, for reasons I never identified. I've always felt this had something to do with the way output was done (byte-by-byte with my own simple buffering). I don't know if PGO addressed an inefficiency in output processing or something else, but it did make me wonder if some of these optimizations would apply to iopipe as well.

On a different front - If LTO and/or PGO proved valuable for iopipe, there probably be an opportunity to create useful sample app to improve dub support for LTO/PGO. It's probably not hard to add this support to dub, but having a target app would make it concrete. Small stuff like that can make it easy for others to take advantage of these technologies.