On 10/22/2016 09:23 AM, Cedric BAIL wrote: > On Fri, Oct 21, 2016 at 3:31 PM, Stefan Schmidt <ste...@osg.samsung.com> > wrote: >> On 22/10/16 00:14, Cedric BAIL wrote: >>> Before I embark on a crazy idea that may just break everything, I >>> would like to get some feedback. So one of the problem we are facing >>> with EFL is that with all those separated library we end up with some >>> serious time during application startup dedicated to linking. A work >>> around has been quicklaunch, but it is mostly unused. Also it does >>> only improve things once it has started, not much during startup time >>> where you still have to do all the linking. >>> >>> With PIE and -rdynamic that we use today on quicklaunch binary, we use >>> dlopen to get symbol from it and load this binary as if they were >>> library... So maybe we can actually use that same mechanism to >>> actually statically link efl with the quicklaunch server binary and >>> make all efl .so library just a symlink to that binary. Now, >>> enlightenment could actually try to rely on quicklaunch to start >>> itself and start other application. This should speed up boot time and >>> application start up time. The reason to make it the default way of >>> doing things is to make sure that it is maintained and work. >> >> Are there actual numbers about speed improvement? Are we really needed >> this speedup so badly? As you can already see from this two sentences >> I'm not really in favor of it. See below for some arguments. > > Yes, it does, but really depends on your hardware. For example, on > Raspberry Pi out of the 4s it takes to startup elemines, 1s can be > saved by quicklaunch. We are talking of a 25% improvement here. It > will also likely push us to improve further quicklaunch > infrastructure. We should be able to preconnect to X/Wayland and save > for the new process that is starting. We should also be able to pre > load the theme which would also save a lot of memory as those data > would be shared among all process. Elementary should be able to pre > load profile too and save that to every process. So first step is a > 25% win for sure. Further down the line, I bet we can save up to 60% > of our startup time. Basically some people are trying to push E/EFL > even further into smaller embeded device and they are requesting our > assistance. > >>> Now some of the drawback. First it is a trick, meaning most people >>> that will try to dig in will get confused at first on what is going on >>> and we need to document it. Building EFL is going to become even more >>> complex (I don't know yet how to generate the proper symlink), let's >>> enjoy more of the autofoo dark art. >> >> To be honest here, this one alone is a killer in my opinion. What we >> have is already complex enough. I often enough find myself in situation >> where I bang my head against the wall until I get the system to do what >> I want. > > Yes, that is not going to improve this way for sure. > >>> All binary will happear as if they >>> are just a fork of enlightenment and you will need to use some flags >>> to ps/top and friends to ask them to read /proc to get the new command >>> line otherwise all binary have the same name. >> >> And that one is the nail in the coffin in my opinion. >> >>> I think that quicklaunch will require also to be improved by being >>> made more robust/with a larger set of feature (nicely opposing goal). >>> Eventually it should handle application restart for example (What >>> enlightenment_start does today)... which annoy me a bit. Also we would >>> likely be on a path to reimplement systemd --user here. Something I >>> have tried to avoid for some time. >>> >>> Ok, does anyone see some serious blocker to this idea ? Impact on >>> packager to much ? Something I missed ? Something that need to be >>> clarified ? >> >> I have a hard time to see that this drastic change is really worth some >> improved launch time. Especially when you keep in mind that we are >> planning to merge some of our libs anyway thus reducing the amount of >> linking. > > I do think we will never save as much nor open ourself to all the > potential optimization that quicklaunch provide b merging a few > library. I don't have comparison there, but from above number you can > guess that it will be below 25%. Also this approach is I think nicer > as we do not need to forcefully merge library into weird name that > have less sense and endup with endless debate, like what does efl_core > integrate and so on. The only merge I would still go with is > efl/eo/ecore as they are clearly linked strongly by behavior now. > I think that given the long term plan has been to merge libraries, its only really worth while if the speedup vs the merged libraries is significant and if it really is only systems like rpi's that are having enough issues for it to be worth it maybe it should be a configure option for people building on those systems so general purpose distro's stay as is, the downside of that though is it wouldn't be well tested. --
Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
