On Fri, 21 Oct 2016 15:14:20 -0700 Cedric BAIL <[email protected]> said:
i've been mulling this. i followed the feedback so far. basically 2 main things: 1. this is intended to improve performance. especially startup times. 2. this is highly problematic in terms of portability and is going to create lots of code and build paths. 3. this makes debugging and other things a nightmare (ps names are all the same .. well depending on tool etc.) 4. generally the issue of complexity in our build requires for portability etc. #4 isn't something we can solve right now, but has a better solution if we go for a greater internal redesign. but not today. some other day. we have to live with what we have right now. i am always for improvements. but this really makes this method a very very very hard ask to do this. i've thought about it and i think this is far TOO radical a change as it means different execution methods, library production, linking and so much more os by os. it's kind of insane though theoretically doable on *nix. i've checked and PIE seems to be urtterly unportable (windows can't do it based on my reading). the proposal would be workable ONLY if we could do it unversally so it wouldn't bitrot and it'd work. this is actually why quicklaunch did .so's instead of PIE because that WORKS portably.... so here is what i think is sane: 1. merge libraries aggressively. this reduces linking time BETWEEN efl libs and thus an efl lib .so when loaded has the libs that were merged already linked together. i propose we try and get down to maybe 3 or 4 .so's this will close the gap. how do we make this portable? well on *nix we can install symlinks from our old .so major versions TO the new merged ones. but what on windows? the best i can think of for windows is produce "empty" dll's that ONLY contain like a dummy function and the correct linking to other efl libs they depend on eg if we merged eina, eo, ecore, efl into "efl" then eina depends on efl, eo, depend on efl and ecore depends on efl. thus link any one of these and you got your symbols from before plus more. this solution ALSO works on *nix ... so we could use it as a start with symlinks being an optimization of it. yes it means 2 install paths unfortunately. we COULD do it as a post-install that "rm's" the .so's we installed and replaces them by symlinks which makes this kind of sane to keep around. 2. move quicklaunch further down to core (efl core) so its not only up in elm land. this would make it a core capability. we STILL should load .so's/dylibs or dll's if there, and try PIE binaries... but we should work here on windows too. make it a core feature low down the stack 3. use quicklaunch mode for e. since efl will be there then this will work. this does not MEAN we have to use it for all apps nor does it mean we MUST use it for e... but this would help these above should get almost all the benefit of the PIE thing with the least of the downsides. we still have ps name issues though. :( we need to dig more to try our best to make this "ok" but this means we still work normally. as long as the "quicklaunch" binary uses very few efl symbols, loading efl libs and linking will be a much lower cost as we do less intra-lib linking and minimal app <-> lib linking. in fact we could make a single libefl.so as a build option if symlinks and dependency .so's as above work. this should be almost the same cost as the pie binary proposal but is portable. > 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. > > 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. 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. > > 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 ? > > Have fun, > -- > Cedric BAIL > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
