On Mon, Oct 24, 2016 at 10:31 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Fri, 21 Oct 2016 15:14:20 -0700 Cedric BAIL <cedric.b...@free.fr> 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.
It won't create lots of code and build paths. In fact it doesn't even need two build paths. It just needs to uses all .la files for building quicklaunch and can be rolled in, in parallel to current system. Just the link of the quicklaunch binary would be different. Next step would be to make a build option that setup symlink to that binary. Finally that option would be the default, likely only afffecting the install process. I don't think that create a lots of code (There should be no code change) and build paths change at all. > 3. this makes debugging and other things a nightmare (ps names are all the > same .. well depending on tool etc.) This is exagerated. Again just need to pass the right command line to ps/top and problem is solved. Can easily be documented and we can also provide a script that does it until we provide some nicer application there. > 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. Hum ? How ? I don't see how we can have good portability without a complex build system. Would be interested to know more by what you mean here ! > 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.... Windows is anyway another platform with a lot of specificity. Quicklaunch will never work there as there is no equivalent to fork anyway. Emulating what PIE allow is also mostly impossible as initialization of a library is different as what a binary require (Even with ALSR). Anyway we already have different code path/build differrence for Windows and Linux and this one is not a new one. As in, it won't increase the difference much. As for the change, they will be the same for all Unix. It is a compilation option on just the binary plus a static linking of all efl to it (basically an ifdef with a lot a +=). So I disagree here with your assesment of the complexity introduced in our build system. The main change is going to be on install which will be made by doing symlink to that executable. > 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. Wouldn't that not work due to DSO ? No idea if that would work with Windows. Also, I am not to sure it would improve things that much as you still need to load a library, agreed an empty one, but still need to load one. It will also be a lot more work than my proposed change as it require to shuffle all the code around and create a set of new empty libraries. > 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 We are already doing PIE binary. As stated above Windows can never have quicklaunch in any form (No fork, and library vs binary can't be initialized in the same way). Also what do you mean by further down in the stack ? I like it in elementary as it enable us to later optimize loading of profile/theme which wouldn't be possible in the lower level. > 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 That is what I want to avoid. Having a random path where we may have it for some application for some user on some platform. I really would like this to either be used by a large portion of the user base or not bother. In my opinion 3. doesn't change at all from current situation as in dead code lying around. Also if we start to enable quicklaunch in enlightenment, due to the way enlightenment_start monitor enlightenment, this means we have to seriously change the way enlightenment_start work. So either enlightenment always rely on quicklaunch or it never rely on it, because the alternative of it relying maybe on it, is a receipe for duplicated code that bit rot in my opinion. Enabling quicklaunch in enlightenment means moving process monitoring to quicklaunch and adding the ability to start a binary in case of a crash. Btw that means that we can provide the same backtrace feature we do provide with enlightenment for all efl application started by quicklaunch. This would improve debugging users issues quite a lot, something we can't do currently. > 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. I have absolutely no idea what you mean here. The point of quicklaunch is to load efl and force a resolution of all symbol once (this reduce future memory usage and runtime cost), you would even start it by enforcing the linker to resolve all symbol. I am confused ! -- Cedric BAIL ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
