I don't know how portable that would be??? I don't think /proc is available by default on most non-Linux Unix-like OS I use...
On Fri, Oct 21, 2016 at 11:31 PM, Stefan Schmidt <ste...@osg.samsung.com> wrote: > 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 > ------------------------------------------------------------------------------ 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
