Boost 1.53

[Zini]

I do build single-threaded because -j2 still takes a good half hour, and having both cores pegged degrades my system's responsiveness and overall usability while I'm waiting for it to finish.

Okay. That explains it. Had me puzzled for a bit.

I did a bit of a cursory inspection while doing my test run and it seems that the mwgui subsystem and some parts of the editor are especially slow to compile. I doubt anything of that is boost's fault. I doubt that we can do anything about the editor. There may be room for improvement in mwgui, but I don't expect a huge difference. I already used up most of the optimisation potential when I cut the build time in half a few months back. Sorry, OpenMW is just that big.

[lgromanowski]

We could try compilation of OpenMW with gcc and precompiled headers - usually it improves compilation time.

// EDIT: Here are some CMake macros which adds precompiled headers support:
https://gist.github.com/larsch/573926
http://www.cmake.org/pipermail/cmake/20 ... 12360.html

[lgromanowski]

Problem with launcher compilation (the one from first post in this thread) is fixed - I hardly ever use launcher and I missed that it wasn't compiled.

[Chris]

I did a bit of a cursory inspection while doing my test run and it seems that the mwgui subsystem and some parts of the editor are especially slow to compile.

It also seems to be especially "touchy". The mwgui subsystem has a habit of fully rebuilding when unrelated headers get changed, as does the mwclass subsystem, which tells me they're (indirectly, at least) including headers they don't need.

I doubt anything of that is boost's fault.

I'm not sure. I think you may be underestimating the effect Boost has. Or maybe I'm overestimating it, but it's well-known that Boost has a terrible effect on compile times.

I already used up most of the optimisation potential when I cut the build time in half a few months back. Sorry, OpenMW is just that big.

I recall someone saying they managed to cut compilation time down further, but I can't remember who/where and the search isn't being helpful.

[potatoesmaster]

I recall someone saying they managed to cut compilation time down further, but I can't remember who/where and the search isn't being helpful.

I have made some changes to improve build and start-up performance. I was able to reduce build time of the openmw project on my system from 16:30 to 4:20, and the components library from 2:00 to 0:12.

Quoted from here.

[Zini]

It also seems to be especially "touchy". The mwgui subsystem has a habit of fully rebuilding when unrelated headers get changed, as does the mwclass subsystem, which tells me they're (indirectly, at least) including headers they don't need.

Yes, definitely. There is also quite a bit of code in there, that doesn't belong into mwgui. Overall mwgui is the dirtiest subsystem we currently have.

I'm not sure. I think you may be underestimating the effect Boost has. Or maybe I'm overestimating it, but it's well-known that Boost has a terrible effect on compile times.

Yeah, measuring is the only way to say for sure. But in absence of more data I stand to my position. We aren't using any of these very expensive boost libraries. I doubt that (for example) boost::shared_ptr is much more expensive than alternative implementation (unless it is pulling in other boost libraries I am not aware of).

We could try compilation of OpenMW with gcc and precompiled headers - usually it improves compilation time.

Precompiled headers are something I am quite sceptical of. Always seemed like more trouble than they are worth. And Qt's macro stuff is probably making it worse.

[Zini]

Finding plenty of unnecessary includes in mwgui (plus a lot of other ugly stuff). I will add a first cleanup issue to the tracker, but I expect mwgui to keep us busy for a longer time.

[sergeyshambir]

Precompiled headers are something I am quite sceptical of. Always seemed like more trouble than they are worth. And Qt's macro stuff is probably making it worse.

When Erik Verbruggen did finished precompiled headers support in QtCreator clang integration plugin, reparsing and code completion became 3-10 times faster. But it doesn't affect code generation, of course.

Reparsing random OpenMW file with this plugin takes 3-5 seconds at average. It took 0.5-1.0 secs for random QtCreator file, and takes 0.1-0.2 sec with pch support.

[sergeyshambir]

btw. over an hour sounds excessive. I just ran a test and a full rebuild takes me 2 minutes and 23 seconds. I have a top of the line CPU, but still. You are not building single-threaded, are you? May a ask the specs of your box?

Do you have SSD on this system? Probably OpenMW build time is IO-bound, so precompiled headers with stdlib and boost will decrease IO load; benefit will be sugnificant on systems without SSD and especially on Windows.

[Zini]

Do you have SSD on this system?

Nope. Just an ordinary old-fashioned HD.