Hello. On 22/10/16 00:53, 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.
And by making it the default your are forcing this quite ugly change to all EFL users while only certain hardware setups would really see a significant benefit. 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. 4 seconds?? Full 4 seconds to get started? I have a hard time to believe that. Maybe some of the system configuration is badly? Really slow SD card? And anyway, what does elimines do the other 3 seconds of startup? Does other efl apps have the same problem? Terminology? Rage? You are asking for a drastic change with quite some downsides here so I hope it is not just based on data from one app in one hardware configuration. :) 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. You are asking for it as default! Not as some way to make EFL better suited for specific scenarios. A big difference in my eyes. I understand the not being tested problem well enough (I deal with not normally tested code paths myself during all the QA work), but that should not mean we make something very specific our default. Default should be generic. e are not enabling architecture based compiler optimizations either but leave that to the user. >>> 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. I your proposal we would just need to live with this? >>> 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. We might end up with an endless debate here instead. :P More serious, the libs merge that is doing discussed and fought mostly about is the efl/eo/ecore one and exactly that one you want to do anyway. Are there really so many discussions about the other lib merges? In any case that leads away from my main point. What I don't like is that I hardly see any data that would support such a drastic change. Even more I oppose to having this the default and making everybodies life harder to even get the name of the binary. Now you need to remember commandline options for debug tools because you use E as window manager... regards Stefan Schmidt ------------------------------------------------------------------------------ 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
