On Thu, Oct 15, 2015 at 2:44 AM, Carsten Haitzler <[email protected]> wrote: > On Wed, 14 Oct 2015 18:56:29 +0100 Tom Hacohen <[email protected]> said:
[snip] > now ... topic digression > > now to a wider reason i want to bring this up now. every lib we have has some > global vars we write to. that means every lib has AT LEAST 1 page of memory > that is modified PER PROCESS. that means our mem footprint for these globals > scale by number of libs AND number of processes. we have too many libraries. i > am DEAD SET AGAINST adding more library .so's to efl. we have to do the > REVERSE. we have to REDUCE them. every lib has not just a single dirty page > for > these globals, some have a few of them. so we're likely wasting about 30-60kb > PER process. because of the massive number of libs we have. this does not > include the fact that mappings are at BEST page aligned. that means if we have > 4132 bytes to load, we actually consume 8192 (2 pages). so every mapping comes > with a rounding "overhead". a quick count shows we have about 105 mappings in > memory .. just for efl library .so's, if we on average we use half of a > rounded > page - that's 200kb of wasted memory ... just for rounding of mappings. every > efl lib has at least 3 mappings from the .so. add on the modules (i count 8) > and tats another 24 mappings - so just under 50kb. sure - most of this is > read-only and thus is a single cost across a whole system. but keep in mind > that on the lower end of things we want efl to run on systems with 32m of ram. > wasting 200-250k ... matters when you have only 32m. > > so to that effect in future we MUST merge libs. MUST merge modules. this does > not mean we have to rename functions, but we need to build differently. my > take > for NOW is that we need to do this: Do we really need to start putting everything into one big pot ? EFL has had static compilation support for a long time now, and if it is broken, it is easy to put back in place. We can even make sure that jenkins test this configuration every day. The bigger question here is what do you want to put into those 32MB ? 32MB was the configuration I had with Elixir a few years back. That was enough for running a full JS VM, but not for a desktop. I am pretty sure at 32MB, you do one application (a JS VM, a Lua VM, whatever VM), but not really a real multitask environment. In which case, the strategy of reducing the number of write page for eo doesn't pay as much, or is maybe even counter productive. Or are we trying to target doing a multitask environment in that budget ? If so, then the challenge is way higher than just tracking our 200Kb of wasted memory. We have to put some serious though on how to do so and start chasing every little bit of duplicated memory, even find how to do so accross process. That's a huge challenge. > lib... > > efl, eina, eo, emile, eet, ecore, eio > -> efl > > ecore_input, ecore_input, ecore_audio, elocation, ecore_con, ecore_ipc, > ecore_imf, efreet, efreet_trash, efreet_mime, eldbus, ecore_file > -> efl_sys Here, I am on the same opinion as mike. Efl_Network make a lot of sense. This means we can actually get a headless configuration of Efl for network task only. Otherwise Efl is never going to be really useful in a network context. For extending the user base, I think spliting this is better. > ecore_drm, ecore_x, ecore_fb, ecore_wayland, ecore_input_evas, ecore_imf_evas, > ecore_evas, evas, edje, emotion, ector, ephysics > -> efl_gfx Why not ecore_input and ecore_imf ? They would be directly used by efl_gfx and would force a dependency on efl_sys that would otherwise not be needed. Which means you could have a setup where you either don't need efl_gfx or don't need efl_sys otherwise why not merge them ? > ethumb_client > -> stay for now (be replaced in future with a non-dbus file "preview" > infra that doesn't require a central daemon - things like SMACK make ethumb > pretty pointless, so move it more to a fork+execced child slave process to do > the heavy lifting so permissions are inherited from the parent). This would also solve a few portability issue... > eeze > -> stay for now (be replaced with a high level device abstraction that > doesn't look like or depend on linux sysfs at all) > > elementary > -> stay I would say, stay for now, but on the long term we want a cleaner Efl_Widget infrastructure that rely more on Efl_Model and Eolian properly (With also less useless widget and more run time widget infrastructure, aka project Bob). > for modules things are harder. ecore_evas and evas should merge really. the > module elm makes for edje should be removed and done via api to register the > module instead of loaded. prefs module in elm - tbd. imf modules are hard to > merge. so we can get rid of 2 modules there. > > so at 3 mappings per lib, and we go from 8 modules to 6, and from 35 libraries > to 6 (without breaking api or abi - we use symlinks to keep old .so lib names > in place) we save 31 * 3 mappings (every mapping is a cost) so 93 mappings > saved. that's 186kb saved... just be generating different binaries (.so > binaries). the bonus is also that compiler can link-time optimize better > within > each .so, startup is faster as there is less seeking and fewer syscalls to set > up LOTs of mappings. even better - with larger .so's we can feasibly use jumbo > pages (2mb pages) which cuts down overhead a LOT. sure - doesn't save memory > but the closer to a 2mb boundary we are the less it would waste. > > the point being - without breaking anything we can be far leaner and faster. > this DOES lead to packaging issues though now as you cant ship wayland > separately to x11 support - you need to build efl pkgs in varieties. x11 only, > x11 + wl, or wl only. though at this point you are forced to do that for > elementary anyway so it's no WORSE than we currently are. > > in the end i want to see ALL the x, wayland, windows, cocoa, fb, drm etc. > stuff > all merged into one module per "system". we need to have a SINGLE system > abstraction that covers low level (upower and friends in ecore) and higher > level (ui/gfx). this would be a goal for efl 2 imho. > > ... so comments? keep in mind that this is a direction we pretty much have to > go, we're really just going to argue the details, unless someone can convince > me otherwise. i've spent a LOT of time thinking about this... :) The main issue I see, and this is the main difference we have today with what we had when I was doing Elixir, Eo force all eo_do call to be virtual and duplicated for legacy. This means that in our current code base we have basically doubled the number of entry point and they can't be easily simplified while compiling them statically. If we started to move all our call to eo_do internally, we could at least have the static compilation eliminate unecessary legacy function, but it wouldn't be able to remove the rest of the API that is not used anywhere. Arguably, if we do target to only have one VM on this 32MB system, then all Eo API would have to be binding anyway and we won't be able to simplify anything. So defining what you want to put into those 32MB of RAM is I think very impotant to see which kind of path and optimization we need to drive in. My personnal opinion is that a 32MB system will be better of with a LuaJIT single VM/application that manage multiple script itself (and go all out static). Also I think that we do still have a user base that needs some good configuration of our code base. Onefang being just one example of them, clearly the most vocal one on this ML. As far as I know the other are more silent and stopped using recent EFL sticking to 1.7. I would prefer here to be more inclusive and I don't think there is any real cost into supporting those configuration #ifdef as they are already needed for portability reason. Ecore_Wayland. Ecore_X. Ecore_IMF on Windows ? Not really. So again here, we can get Jenkins to build a very minimalist version of EFL and continuously check it. The cost of maintenance should stay low if not make our live easier for portability (Windows, MacOS. Android, ...). Now what we need is to define what this minimal configuration should be and put that into Jenkins. -- Cedric BAIL PS: I think we have completely hijacked this thread and should maybe start a clean new discussion on where EFL is going. ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
