Nobody said anything about GL. On Fri, Jan 12, 2018, 6:02 AM Carsten Haitzler <ras...@rasterman.com> wrote:
> On Thu, 11 Jan 2018 17:13:22 +0000 Mike Blumenkrantz > <michael.blumenkra...@gmail.com> said: > > > Thanks for your valuable input! We'll take it into consideration. If you > > have feedback for the developer team in the future, please be sure to > > include technical data to support your comments so that we can evaluate > it > > fairly. > > why is it that when i read the above it's just dripping in sarcasm. i > smell it > dripping between every line. the snideness just oozes from it. > > now i wasted a good 30 mins redoing numbers below that i already pretty > much > summarized with "don't use lots of processes" as i've spent years looking > at > this data, but obviously my history, experience etc. mean little to you. > this is > stuff you should have done before choosing this path. you obviously didn't > given > "please provide technical data" above that you seemingly don't have. > > if you have a gadget as a window then that window must have a buffer and > that > buffer consumes memory where otherwise no buffer would exist. did that even > need to be justified? just do the math. a 40x40@32bpp gadget will consume > at least ~6k of ram and if gl rendering is involved that'd be 12 or 18k or > so. > maybe more. that's a start. > > now let me add up the dirty pages just from loaded .so files (dirty pages > are > private per-process pages) for just a single efl process like > enlightenment_askpass that has the same linking as a gadget: that's about > 1800kb of dirty pages PER PROCESS that is overhead. (1872kb to be exact). > pmap > -x. use it. it's a rough tool but does the job for this topic. > > now if you want accelerated rendering with gl... that'd need a gl context > and > gl dependencies loaded. dirty pages loaded from .so's goes up to 4764kb ... > > now heap memory usage when using gl goes up too. gl contexts and so on > (heap > meaning via malloc etc.) and this goes up from 4.9m to 8.8m just to have > acceleration. this will multiple by the number of processes. > > now there is also the overhead that every process loading an edj file has > to > have its own malloced data structures for that edj file. if you look at > detailed massif data you'll find that edje + efreet + fontconfig > + openssl will malloc privately per process just to load the theme, shared > efreet cache files and cached fontconfig data etc. a total of about 1639kb. > > let me do the math for you: > > 1639 + 1872 (if software) = 3511kb per process overhead just for what i > mentioned. it's more with each process's own stack and other things also > loaded. but let's call it 3.5m. > > now if we want gl acceleration that goes up by ANOTHER 3.9 + 2.8m = 6.7m. > so > 10m per process overhead if you want to use acceleration to render and not > the > cpu. at least as a new stand-alone process. > > for a more coarse measurement, just do the simple one: run free; run > enlightenment_askpass, then free again (with system otherwise stable): > > without gl mem usage goes up by 10848k. with gl it goes up by 21772k. this > is > nvidia drivers btw here. > > there's also all the added overhead now of having to launch all the > processes > that are gadgets and process launching is not cheap. it's slow and costly - > especially all the post-process work like loading edj files, decompressing > the > same data multiple times etc. etc. ... > > are you telling me you didn't do any design evaluation or numbers before > deciding on a path and you need me to do this for you? i have done these > kinds > of numbers again and again over the years and they consistently show the > same > thing: > > 1. every process costs. especially if it's complex with lots of libraries > and > data sets. it's 100's of kb just for the simplest basic libc using process > stretching into multiple mb for those using larger toolkits. and that's > just for > common shared data that isn't specific to that process. > 2. opengl adds a mountain of overhead on top per process. > > most of these are very hard to get rid of and designing something that > actively > works against "the way things are" is a very poor way of doing things. > especially to everything enlightenment is about, like being efficient. > > > On Thu, Jan 11, 2018 at 3:41 AM Carsten Haitzler <ras...@rasterman.com> > > wrote: > > > > > On Wed, 10 Jan 2018 20:38:27 +0000 Stephen Houston < > smhousto...@gmail.com> > > > said: > > > > > > i'm going to put my take on this: i think this is bad. it flies in the > > > face of > > > everything e was built to do. to be efficient. having a process per > gadget > > > is > > > horribly inefficient. this is precisely what helps bloat out gnome and > kde > > > memory footprints and what has kept e lean. > > > > > > while avoiding e crashing due to a bad gadget is a good thing, the > > > following is > > > just a bad way to do it. > > > > > > 2 other alternatives: > > > > > > 1. have a SINGLE "gadget process" to hold all gadgets and load modules > into > > > this process, so we don't have 20 processes, but instead have just e + > > > gadget > > > process. > > > > > > 2. remote ui. gadgets could be written in any language that can do > stdio. > > > they > > > echo/printf commands to e to create objects and change their state, > and e > > > "echos" back on stdin events and things the gadget should know. your > gadget > > > could be a stripped down super-lean basic libc executable. python. > shell > > > script. anything that can do stdio. while this still has 1 process per > > > gadget - > > > it's for the back-end only and this should make then far leaner than > with a > > > full ui. > > > > > > i actually wanted to spend time on #2 but am busy with efl atrm. #2 > would > > > be > > > great because it'd massively lower the work needed to quickly make a > > > gadget of > > > your own. write it in python or shell quickly and dirtily and life > would be > > > easy. > > > > > > > Hello, > > > > > > > > I would like to point everyone to a new wiki page we have that > details > > > > developing gadgets for Enlightenment using the sandbox method. > > > > > > > > https://www.enlightenment.org/develop/e/sandbox_gadgets > > > > > > > > Feel free to use the guide to create cool new gadgets for E and make > sure > > > > you contribute back feedback about the guide so we can improve it as > > > needed. > > > > > > > > Thanks! > > > > Stephen (okra) > > > > > > > > ------------------------------------------------------------------------------ > > > > 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-de...@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" > -------------- > > > Carsten Haitzler - ras...@rasterman.com > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > 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-de...@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-de...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > Carsten Haitzler - ras...@rasterman.com > > > > ------------------------------------------------------------------------------ > 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-de...@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-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
