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-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
