On Sun, 19 Nov 2017 16:15:17 +0000 Peter Flynn <pe...@silmaril.ie> said:
> 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. We could be far better with reliability. We have too many dark corners and code paths that just don't get tested widely enough. We really rely on, and hope users can help test them and help fix them, or at least have an efl+e build with debug symbols so we get backtraces in ~/.e-crashdump.txt that might actually ultimately help us find it... :) Suffice to say that if I see a bug ... I fix it. If I can reproduce it enough to do so. Finding out how to reproduce often is the challenge. My day to day running of E even from "git master" is pretty solid and I get incredibly grumpy if that gets broken on the odd occasion and I'm fast to fix or revert changes that actively cause such behaviour. > 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. Actually I didn't have a particular priority order here... Just reasons. :) > > 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. Well for E it's config AND state in the same file. Like your DB is holding state for your "web app" knowing what users are and are not logged in, their session data etc. etc. > > 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. Well it's a trade-off. You write less this way, But a crash, or pulling the power plug may then lose much more state. E doesn't write immediately. It queues a write and delays it for a while (how long it delays depends if you are on battery or AC ... :) ). It probably is in the realm of between 10sec and a minute, then it'll write it out. So a balance between writing too much and making sure we get our state to disk in case bad things happen™. > > 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 why E does shine there. Because thought went into working well when things were more constrained. > > That's 6.6 times more space. > > If it's constantly rewriting, this certainly is an issue. Well as it stands... with them all compressed they still consume ~2.6M on my system here (that includes all the 10 backup files per cfg file). That's not insignificant. We could drop to only 1 or 2 backups easily enough. I chose 10 to be super paranoid. dropping to no backups is still 432kb compressed. uncompressed text with backups would end up 20-30M. > > 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 :-) still - it's a common path. i'd done config parsers twice before for e (e 0.1->0.13, e 0.14->0.16), and after that i had no desire to do it again. i was making my choices for this back in ~ 2001->2004 so imagine the state of the world back then. I wrote eet to function as a kind of "swiss army knife" for files that are read very often, possibly rewritten regularly (maybe between every 10-30sec or maybe just a few times a day), and where I want compactness, reliability etc. ... one aspect of "don't use a text file" is that it makes it HARD for users to mess them up. Edit a cfg file and put a parse error in. What does E do when it finds a parse error near the beginning of it's cfg? It is heavily reliant on it to know what to do. You also now have to gracefully detect that parse error and tell the user what it was so they can fix it. If you make them binary ... this really pushes the user away from making such mistakes. Tools like the eet cmdline will take care of things before E reads stuff. Even then it shouldn't be needed because E will manage its own config itself via the eet library calls and thus... this should all be moot really. > > 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. well actually i kind of just touched the surface. every time we create a window, a button, a checkbox, a list item in a list and even scroll around (where we may be creating and destroying visible items on the fly while you scroll to only keep the visible active set around etc.), we're potentially opening and decoding an eet encoded file and data structures. there are caches in between to minimize this, but the entire UI is continually "paging data" from these files (edj theme files). We're digging data out all the time as your UI responds. This saves memory as we're only loading what we need when we need it and not "everything once at startup", but it does mean the whole process got though and care and optimization. The config files are just piggy-backing on all of this work to save time, effort, improve reliability and performance. It'd be pretty silly to do anything else. Especially when for the odd occasion once a in a blue moon that you need to poke around the config files... there are tools for that for the advanced users (as I'd only expect advanced users to go digging around dot files with a text editor). > > 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. can you be more specific with details and examples? > > 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 THAT file doesn't have an encoded data struct. it's just a plain string in the key - that's all it needs. error is misleading. it just can't decode it because it's not validly encoded data. instead use -x for the profile.cfg. the files inside the profile dir (e.cfg etc.) do have encoded data though. basically like files on a filesystem you don't KNOW the type without inspecting it (extensions are a convention that might often help determine type - but it's not eeded in eet files as the code doing the read or write ... or makefiles/scripts building the files know the data that is there). :) > > 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. just thought i'd explain everything behind it. It's not how most other GUI apps or desktops have chosen to work, but it is how I chose to do E and it's one of those things that makes it different, and it's that difference that often gives E and edge somewhere where others fall short. We're not perfect and need to improve in many areas, but in some at least we're doing well. > ///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 -- ------------- 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
