On 19/11/17 02:01, Carsten Haitzler wrote: > On Sat, 18 Nov 2017 23:21:11 +0000 Peter Flynn <pe...@silmaril.ie> said: >> E has always worked so well I've never needed even to think about this, > > That's how it's meant to be... :)
It's one of the major areas where E scores over the rest: reliability. It very rarely fails or hangs or dies, and when it does, it's usually for a good reason, and it doesn't damage things when you just restart. Some things could certainly be better-worded, or better-placed, especially config options in the menus, which are deeply misleading, but this is an interface/usability/documentationproblem, not a code execution problem. >> OMG they're binary files. Good grief. Is this for speed or some other >> reason? > > 1. Speed. Always good. > 2. Code re-use (we already have binary for our theme files etc.) > 3. Ease of use from code (far less code). Big benefit to the devs. > 4. Reliability (The code re-used is tested and used a LOT). I'd actually put this at #1 above speed. > 5. Size (they are compressed) I'm not sure that's really relevant these days, but I can see it would have been an issue whe E started. > Ask yourself the question - why do people use Mysql or > Postgres or Oracle instead of just writing everything into big flat text > files? I never do, fortunately. My work is all XML. System configs have no place being in a relational database. > Enlightenment is continually writing out config AND state to these > files. Aaaaah. *Now* we get to the real reason :-) This is good to know — one of the biggest problems with lesser systems is that they don't remember your setting changes because they don't rewrite the config file until you log off or shut down. > If you decompressed those config files, they'd be 3-5 times the size. Right, but as I said, with modern disk speeds and capacities this really isn't much of an issue. Where it helps E shine is when you install it on older, slower computers. > That's 6.6 times more space. If it's constantly rewriting, this certainly is an issue. > As for speed. I wrote up a good comparison of eet vs libjson (and indirectly > libjson vs libxml) on our phab news page a long time ago: Yes, that's understandable. > Using something like json (with libjson) would make reading 7 times slower. > Writes 40% slower. On a cold read (fresh boot) 10 times slower. Using XML > would > have been far worse. Only if you pick a dodo parser like libxml :-) > But where it matters to me is read times as that determines time for startup > of > E etc. ... and thus determines what users perceive as responsiveness. Good selling point. > But ... speed is just one goal. We could do better I think and chop memory > usage > down, but that's for a future library or feature of eet, But I have plans in > the back of my head. I'd concentrate on interface usability first. Having a fast startup is wonderful. Having menus which baffle the user is not so great. > But the REAL place eet shines is in ease of use for the programmer. This is impressive but — I'm sorry — of zero interest to me as a user. I'm delighted it's so nice for the devs to work with, but it's not a selling point except insofar as it contributes to stability and speed. > It's unsurprisingly called: > eet Been playing with it. Fails if you try to execute it within the ~.e/e folders (you must run it from ~/), but otherwise fine. peter@noah:~/.e/e/config$ eet -d profile.1.cfg config ERR<3228>:eet_main bin/eet/eet_main.c:233 do_eet_decode() cannot write to standard output > Run it for help. It can list content of an eet archive (eet -l filename). All I wanted. Great utility. > I made this choice. I wrote the code. I'm not actually crazy. I thought things > through carefully after many years of experience. Given the parameters, you made exactly the right choice. ///Peter ------------------------------------------------------------------------------ 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
