Compiling Ceph on an older machine (20-core Ivy Bridge) I noticed that one g++ invocation had racked up 7+ minutes of CPU time. It was librbd/migration/HttpClient.cc, which has 755 lines of code.

Of course it includes 19 include files, 8 of them Boost ones, and in total expands to about 2700 files and a third of a million lines of code, so maybe it's the input file that's crazy, after all.

It all reminds me of being back in the 80s, when you went for a cup of coffee after kicking off a compile. (well, to top it off I'm in a special kind of hell because I'm debugging CMake files, and have to rebuild the whole damn thing repeatedly.)

@pjd I read it somewhere that indeed crazy long compile timed encouraged the Go language creators
@pjd Insane that it ended up being 300,000 LOC. But that’s after preprocessing right? The prepocessor output is often astoningly large.
@atmast cloc on preprocessed code, after filtering out all the line # directives. Even then it’s still something like 700 lines compiled per second.
Unfortunately my fast machine can’t compile it - it’s set up to run a Xilinx workflow for a colleague, which requires Ubuntu 18 :-( Dunno how much good it would do, actually, as it has a lot fewer cores.
At least I don’t have FPGA-level compile times, where 8 hours seems to be considered reasonable.
@pjd I've never been clear on why rbd needed to implement it's own HTTP/S3 client--RGW of course already has one that re-uses libcurl (though it might be replaced with a beast client at some point). So we could probably make that go away at some point...
@monkius I never even tried to figure out how the migration logic works in RBD.
BTW I’m putting the finishing touches on a pull request for LSVD - hopefully I can get some folks to look at it after the holidays.
Funny how getting something to pass the correctness and performance tests at the same time is so much harder…