Hello. On 22/10/16 00:14, Cedric BAIL wrote: > Hello, > > 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. > 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. 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. 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
