162c416fbSEd Tanous## Why does bmcweb use so many headers? My build times are slow!## 262c416fbSEd Tanous 362c416fbSEd TanousTL; DR, History 462c416fbSEd Tanous 5*dfa3fdc3SPatrick Williamsbmcweb at one point was a crow-based project. Evidence of this can still be seen 6*dfa3fdc3SPatrick Williamsin the http/.hpp files that still contain references to the crow namespaces. 7*dfa3fdc3SPatrick WilliamsCrow makes heavy use of headers and template meta programming, and doesn't ship 8*dfa3fdc3SPatrick Williamsany cpp or implementation files, choosing to put everything in include once 9*dfa3fdc3SPatrick Williamsheaders. As bmcweb evolved, it needed more capabilities, so the core was ported 10*dfa3fdc3SPatrick Williamsto Boost Beast, and what remains has very little similarity to crow anymore. 11*dfa3fdc3SPatrick WilliamsBoost::beast at the time we ported took the same opinion, relying on header 12*dfa3fdc3SPatrick Williamsfiles and almost no implementation compile units. A large amount of the compile 13*dfa3fdc3SPatrick Williamstime is taken up in boost::beast template instantiations, specifically for 14*dfa3fdc3SPatrick Williamsboost::beast::http::message (ie Request and Response). 1562c416fbSEd Tanous 1662c416fbSEd TanousThe initial solution that gets proposed is to just move everything as it exists 1762c416fbSEd Tanousto separate compile units, making no other changes. This has been proposed and 1862c416fbSEd Tanousimplemented 3-4 times in the project, the latest of which is below. The intent 1962c416fbSEd Tanousof this document is largely to save effort for the next person, so they can at 2062c416fbSEd Tanousleast start from the existing prior attempts. 2162c416fbSEd Tanous 2262c416fbSEd Tanoushttps://gerrit.openbmc.org/c/openbmc/bmcweb/+/49039 2362c416fbSEd Tanous 2462c416fbSEd TanousMoving to cpp files without handling any architecture has the net result of 2562c416fbSEd Tanousmaking total compilation slower, not faster, as the slowest-to-compile parts end 2662c416fbSEd Tanousup getting compiled multiple times, then the duplicates deleted at link time. 2762c416fbSEd TanousThis isn't great for the end result. 2862c416fbSEd Tanous 2962c416fbSEd TanousTo actually effect the result that we'd like to see from multiple compile units, 3062c416fbSEd Tanousthere have been proposed a few ideas might provide some relief; 3162c416fbSEd Tanous 3262c416fbSEd Tanous- Moving the Request and Response containers to opaque structures, so a majority 3362c416fbSEd Tanous of code only needs to #include the interface, not any of the template code. 34*dfa3fdc3SPatrick Williams https://gerrit.openbmc.org/c/openbmc/bmcweb/+/37445 Doing this exposed a 35*dfa3fdc3SPatrick Williams number of mediocre practices in the route handlers, where routes made copies 36*dfa3fdc3SPatrick Williams of requests/responses, relied on APIs that should've been internal, and other 37*dfa3fdc3SPatrick Williams practices that make this migration less straightforward, but is still being 38*dfa3fdc3SPatrick Williams pursued by maintainers over time. 3962c416fbSEd Tanous- Moving the internals of Request/Response/Connection to rely on something like 4062c416fbSEd Tanous [http::proto](https://github.com/CPPAlliance/http_proto) which, written by the 4162c416fbSEd Tanous same author as boost::beast, claims to have significant reduction in compile 4262c416fbSEd Tanous time templates, and might not require abstracting the Request/Response 4362c416fbSEd Tanous objects. 4462c416fbSEd Tanous- Reduce the bmcweb binary size to the point where link time optimization is not 4562c416fbSEd Tanous required for most usages. About half of the bmcweb build time is spent doing 4662c416fbSEd Tanous link time optimization, which, as of this time is required to keep bmcweb code 47*dfa3fdc3SPatrick Williams small enough to deploy on an actual BMCs (See DEVELOPING.md for details). One 48*dfa3fdc3SPatrick Williams could theoretically determine the source of where LTO decreases the binary 4962c416fbSEd Tanous size the most, and ensure that those were all in the same compile unit, such 5062c416fbSEd Tanous that they got optimized without requiring LTO. 51