 olen Kuuhyppist. Olen tullut tullut kyllä vähän asioista, tämä spring. Kurssitun kohdassa ympäristöryhmä ja kaikkiaan iOS-aikkoa. Ympäristöryhmä on Ympäristöryhmä on ympäristöryhmä, että pysyy vain sekaisen jälkeen. Ei ole edelleen tullut selviä. There are system-shared libraries, but all your code has to be statically linked into one executable. And of course you can have as much data files as you need. And you can, for instance, map in data files into memory that's not restricted in any way. But you can't map in executable code. So that's actually quite a big restriction or big change for the OpenOffice slash LibreOffice codebase. Typically, first of all, we haven't had all these unal components as shared libraries. And there are, in a desktop LibreOffice, there are hundreds of them. And also then some non-unal components are also shared libraries and some are like dynamically loaded libraries for some more or less obscure technical reasons. The rules for applications in the App Store says that the files can be, or some of the files can be as large as two gigabytes, which is quite a lot, of course. There is, however, something that you can easily miss. There is a bot. The executable file can't exceed 16 gigabytes. And this is something that you can, that you notice typically only when you are doing your final work on submitting the application. And then you click on one X pattern and you'll notice this text there. And of course for many applications, that's more than enough. But for LibreOffice, it's not enough because, or it was not enough, because when we link all the code that's needed together, even if it only takes the needed code, anything that's not cold, does not get linked in, it still ended up with something that was very large. And the test application that we use was this type LibreOffice, which is a simple viewer only. And before we started this work, its size was over 90 megawatts, or more or less 90 megawatts. So there was quite a lot to reduce. And this is then an optimized build-down, so this 90 megawatts did not think to do any debug information or symbols. Or rather, stuff that wouldn't be shipped to the end user anyway. And of course, it didn't want to lose any functionality because after all this type LibreOffice is just a viewer, so any real application would need even more functionality. Of course, even if the only link in or the link around links in code that actually gets cold or is referenced, a lot of that is such that it won't ever get used at runtime, at least not on a mobile platform, because you can have, for instance, like a long function and some switch statement, and many of the cases are for situations that don't occur on mobile. One way to get rid of this code is of course to put if defs all over the place, and that quickly leads to quite ugly code, of course, and we didn't want to do that. But only put if defs in the places where it actually helps a lot. So some other approach was needed. And luckily there was one area where we could lose a lot of these 90 megawatts. It's this ICU library. It means internationalization components for unicode. It's what we use to support various character sets and languages and encodings and whatever. Normally all the data that ICU uses gets compiled into a shared library or into code anyway as constant data in the code segment. And that's how we use it on desktop platforms. But when you build ICU, you can also instead create a data file which basically amounts to the actual data is the same structure in a way because this shared library just contains the same data wrapped into a shared library. And then you just have to in the code map this by memory and then I see that this is the data you should use. And the size of this data is 23 megabytes. So that's quite a lot. But there was still quite a lot to go. The next thing we looked at was the local tables. We generate data from manual maintaining XML files. For all the locales we know about. And there are quite many of them because of course we just want to be the one application or desktop application for everywhere in the world. And that's a good thing. But for some application on iOS we can be a little more, or we are creates that application can be a bit more doesn't have to be so all inclusive and drop some locales that they don't think that will have such many customers. And so I added this with locales configuration option that can be then used to restrict what gets built even better to do is also for this data files and not have the data encode but it can be a bit complicated depends on how the data structure contains lots of pointers to other places in the data then to turn that into files that are simply mapped in requires some coding changes that I didn't want to get into at that point. And another source of large data is the dictionaries. This doesn't actually mean dictionaries that would tell what words mean but this is actually like break iterators and stuff like that. And maybe not for Japanese and Chinese spelling check. Word iterations. Word iterations, yeah. And actually I think this is what partially duplicates what's already in ICU. So, yeah, but we are here. Perhaps I'm not even sure if we actually need this or not. But anyway, we don't dare touch it. But luckily in this case this data is quite simply structured so here we can use memory map files instead. And this was, I think, several megabytes. Then we also had large data files for the OvoXML custom shape presets. Just to hear me. This is the generated code from the OvoXML specification. And they used to generate like tons of these very similar classes that had slightly different code or data in them. And Miklos then changed that into instead generate data files that were in that runtime. And do you remember how much space was available? But why that? A few megabytes or something. I think it was done in that ballpark. You can check the size of the generated data. No. It's one and a half megabytes. Okay, one and a half megabytes. And then one thing that we had already been doing earlier was then continued because of this was to split these unocomponents into smaller ones by refactoring. Because some of the unocomponents did quite a lot of things and not all of these functions were such that we were actually necessarily needed in the same application and that could be simplified then. And also we then also did some more aggressive if-deafing in some places that pulled in lots of code. For instance, all the code that we have for help features on desktop it's not really relevant to mobile platforms because help will be a different way anyway or accessibility features, which typically also would be new to the new code anyway. And also extensions for iOS. You can't even have any extensions. It could be against the app store rules. So it's pointless to linking code that has to do with managing extensions. Then we have another thing that also partial, partial at least, duplicates, but they already have in the ICU, all these characters. Conversion tables. Quite many of them are for such encode except or definitely not needed in an application that only wants to deal with modern file formats like ODF and OXML because they basically use UTF-8 anyway. So you don't need anything for some HP Roman 8 or Apple Cyrillic or something. And of course it's the Japanese and Chinese and Korean ones that are really large ones. And these are also now behind the with blockhouse configured option. Then something that was actually quite surprising that it helped a lot faster user a better optimization level for the compiler. It's clandestine so this is not something that the DCC would have. This OZ, it must be about 10 megawatts or something that it helped. It helped quite a lot. Unfortunately, clandestine is not bug free. So a few bugs apparently exist when you use OZ and they were totally randomish. So we just had to look around those places that were miscompound using OZ. Then one thing that you might think of would be link time link time code generation and optimization. Unfortunately, this is not really something that can be used in this case because we have so much code it takes the link very, very long to generate code and optimize it at link time. I once tried it and the linker grew to like 10 times my physical memory size during one hour and I lost patience. Luckily one thing we don't need to think about this how to make the linker actually link in just code that could be used on reference for this reference because that's what it does automatically. And this is based on an actual function not like object files. There is one thing I just studied that when working on this for iOS it's easy to make assumptions based upon how you have done in Linux or seen in Linux but that's something I should be careful with because the file formats are different and the tool chain is different. Then when you are trying to reduce the size of your executable you need to figure out what you should concentrate on and for that there aren't really any really good methods but it's quite manual work or you have to look at the linker map and then just do some script to manipulate it and get the data out in a suitable sorted or processed fashion and we have a script that collects some statistics from the program app file and tell you which libraries from which libraries most of the code is coming or which the largest object files are you can check the file and see what it does and then the final result when we had done this enough was that the total library of this size was 43 megabytes so it was less than half the size but of course when we started and as you might guess this was done for cloud-on so thanks to them for doing this and that's all I had. Thank you. Any questions? You mentioned that you go into Japanese support and you visit for assuming that the iOS would help handle these languages so if you need those to support it Yeah but it's optional only if you use this bit block house which then you can select which character checks or versions are included for instance What about checkspelling and auto execution is it part of this? That's something that is in these data files that are not optional No, that should be present always What's optional is like character check tables for some but they might actually still use these encodings but not inside how they have to work at least I hope so of course Does Android have the same invitation? Not exactly but it's a good idea to of course reduce unnecessary size anyway but on Android there is no limitation on the code size No, there is one Not the same one Initial application size has been You can download this but the initial size is limited to 15 megabytes I don't remember the exact number I think I also have read that it has been moved to this limit So I'm not so sure No, you can in Android load dynamic but there the problem is that the number of these are very restricted at least in some Android versions It was something like 100 libraries and as we have several hundreds we decided to link everything into one shared library anyway because then we can just say what do you guys qualify for Thank you