 Taj praskel je o zelo pristiljnega bljevstva Librofis. Vse je zelo prišal, da je to počutak, načal, da bomo zelo v ponadstvu bar, in sem bilo tudi srednje. Tako, agenda, vse je vse problema? Kaj je soluzija vse? To je vse, da se vse je uvarjali, da bomo izvajali, kaj je začal. In sem videl, da se se izvrživamo, da je tudi statistična. Zato, je to problem, da sem počutila, da je to počutila, da je to počutila, da je to počutila. Znalej se, da je tako bilet. Srečen bilet, da se počutila, da je to dobro bilet, da je to dobro bilet, da je to dobro bilet, da je to dobro bilet. when the library changes and it results in a long developer cycle. So what's the solution, still from Lubosh, improving code, like including only what is needed, using forward declarations instead of include and avoiding templates in headers, and he wrote that this is a lot of work, which I can confirm it is. So codebase is rather old and has seen a lot of reworks, and there are some unnecessary includes in most of the headers and source files, and I think during the last year I managed to clean up approximately half of the files in the codebase, so this is still a work in progress apart from causing build failures. So what is include what you use? It's a simple or not some simple tool to remove superfluz includes, at least that's how they define themselves. It's an alpha quality tool created exactly for codebases like ours. It basically promises to filter through source files and tell what are the unnecessary includes, and once that could be replaced by forward declarations, which are much cheaper to use in header files than the full headers themselves. So how to install it? We need a fresh LLVM8. There are APT repositories available on their website. You need to install those packages listed above, and some Linux distributions like Ubuntu have packages of include what you use. I used that initially, but that was rather old, so the best way to use it is use the compiled latest and greatest version, because it's updated in three to six months time frames. So to build it, first prerequisite is fresh LLVM, and then we need the source code from GitHub, and the commands are outlined here. There is four. I will put this information up to the LibreOffice wiki, but it's not there yet. Build process is detailed in readme.md of the codebase, but these four commands is basically the essence of that. So how to use it? Prerequisite is make VIM ide integration command. Then there is a small tool called bin slash find, and it includes, which was made by Mikroshvajna. You need to call this tool on the files you wish to filter, and it will basically tell if there is anything to throw out of the files, and it will show a long command line of evu, which you need to run. So how to use it? Sorry. Sorry, someone looks for me on Skype. So if you suggest headers to remove, after that you should recompile either the full source, full codebase, or the module that you are working on, and if it does not compile, you should add back the missing headers, and finally remove the unnecessary ones if it compiled. So basically it's commenting out, compiling, and removing. And then we should commit and push together it as usual, and fix any breakage caused by, caused another platform, because I used this on Linux, but sometimes I cause build breakages on Windows or Mac because of platform specific codes that is not seen by evu on Linux. So in action, this is one screenshot from live action. I cleaned up one CXS file in the SD module, and I got three removal suggestions from findUnitedIncludes, and one from the similarly named header files that is also checked by evu. So this is why I always check the header files and then CXS files. On the right side you can see that in the editor, I already commented out those includes, and nice feature of findUnitedIncludes is that it sorts byline numbers, so it's very quick to find in order which lines need to be commented out. Then there is this long command line that is actually run in the background. We need to run this long command line on a different terminal, because if there is a build breakage, like transitive includes, can cause that. This command line shows all these includes that are necessary to build this particular file, and if one of those are only included transitively in those headers that are marked for removal, that will cause a build breakage locally. The output of the long command line can show you which are these transitively included headers, there is always a lot of them, and you can see from the build breakage that what is needed to be added back. So, next. There is of course exceptions. Evu is not a perfect tool, and since LibreOffice code base can break any tool chain, there are exceptional situations for file specific situations, when Evu gives a bad advice. You can list those headers in a module level YAML file, which is called Evu filter underline module name dot YAML, and the next time you run or someone else runs find unneeded includes, those bad advices won't show up again, which is good because for rechecks, and unneeded includes stops whenever it finds one problematic file, and this file is usually updated with every or every second commits. There are more common situations too, that affect many modules, and those are handled by the find unneeded includes script, such as not replacing HPP files with HDL ones, and standard library headers with their debug variants. Such updates are more rarely needed, but sometimes it is needed to update this Python script tool with exceptions. So, about progress. Since April 2018, which is when I started this work, I managed to clean up these modules, these directories. This is the result of 200 plus commits. These larger directories are now done in master. So, first I started to clean up the include directory from bottom to top of the module hierarchy, and since waiting for Jenkins and review is somewhat time consuming, I also started the other end of the tree, like the calc and impressed modules, then charts as well. So, to not lose track of my work, I used this beautiful dependency graph of the project, printed and taped to my office wall. You can get a similar dependency graph using make dump depth png command. And after cleaning up include, I started to clean up the internal libraries from bottom to top, which is now about done until VLC. So, all these are also finished. So, results more. Mezered results of my efforts, I used the bin slash includeblot.evkey script, which measures how many files are included during the build process. These next charts I show were created using that on fresh builds with unit test from stable grid branches of LibreOffice 5.326.4 master, which was end of July. I could get these versions to build on my Ubuntu 18 machine. So, we should start to see differences starting from version 6.1. That was the first one hid by my commits. From 5.326.1, the natural evolution of the project can be seen. And in the bug report about this problem, which is numbered 42949, there is also included a similar analysis from 2011, thanks to micro mix. And I used that here as baseline. So, that's what you see on the beginning. It was about 3.5 time or so, I'm not sure. This chart shows the number of individual files in the code base, including the bundled and built external modules. And these show a slight growth over time. And then, recently, a large jump, and that's somewhat strange to me. So, 6.3 is omitted because it's so close to 6.4, but that's only master, really. And this chart shows the number of inclusion occurrences. We have about 25,000 files, 26. Many headers are included in many of them, which in turn are included again and again in different libraries. And these add up quickly. The total of this number has peaked at about 4.3 million. And now we can see these are down to about 3.5 million. And this is some 15% reduction. And I'd like to take the blame for this, but others also helped with refactorings, like the welding work by Keolan. So, thanks for that, too. OK, so, another measurement is the total number of bytes included, because some headers are small, others large, and including a small one many times might have a smaller impact than including a large one fewer times. And I think this is the ultimate measure of my efforts, because build time depends on the amount of input to process by the compiler tool chain. We can see an interesting bump in 6.1 to 24.5 gigabytes, then slight reduction back to below 23 gigabytes in 6.4, which is interestingly, if you see, about the same as we were in 2011. So, somewhat interesting. Another developer-friendly measurement is the total number of minutes spent with building. Here in this, I try to minimize the non-C++ parts of the build, such as help content, icon teams, galleries, and I did not run the unit tests either, because that's heavy on CPU, but does not really say anything about compilation. And this is consistent with the previous charts, but I expected larger drops. And it looks like that having 16 thread processor helps more with compressing the user column, the red one, to the real people time blue one. But something is not really right with this picture, because since 2011, a lot of refactoring happened. Supposedly, we should do things simpler now than we were doing it back then. Then, apart from refactorings, my work has happened. And basically, we are still at the 2011 level. And so the question comes that, was this all in vain, and is the best achievement I can get, is not getting much worse, is that all? So I looked deeper into the data created by IncludeBlood script and found something interesting. And there is one module that shows some alarming trend. There is a certain component of the project, which shows this chart in its Include sizes. Can someone guess which component is this? Anyone? Miklos? It's boost, yes. So this is the boost library. Somehow it added a lot of bloat to our build process, then it was reduced, then it's growing again. So, future possibilities. Boost slash optional HPP is included for 4,500 times. And removing a single one shows a reduction of 900 kilobytes of input, which is quite a lot if we multiply it. It would be really nice to remove our dependency on this boost optional, since it's so expensive. It's very extensively used and unlike the other parts of boost. There are some platforms that are not really ready to move to the standard library equivalent of boost, which has appeared in C++17. Android is one problem, because it's using G++4.9. But the recent bump in the Android baseline might have helped, because we moved away from one standard library to lib C++, so that might help. And also there is Mac, which would need our newer Xcode version, unfortunately. So I will also continue cleaning remaining modules, like internal libraries and writer, whatnot. So the things between VCL and user applications. And there is one more problem to tackle, and this is forward declarations. These are very useful in this fight, and the view is very keen on finding good replacement candidates for them. But using forward declarations can build the break in configurations that are not tested by Jenkins, like the no precompiled headers case on Windows. And because of that forward declarations are now disabled in find unidid includes, but it would be real nice to have them enabled back. So it would be real useful to have one more Jenkins configuration or even more for this. So that's an issue to tackle commonly. And that was it. Thanks for the attention.