4 ms·
There is some very basic education and industry choices we could make to get a ~4x or so efficiency gain without any substantive increase in development time/ef
by jackmott 9y ago
There is some very basic education and industry choices we could make to get a ~4x or so efficiency gain without any substantive increase in development time/effort/maintance cost etc.
If people graduated from college with just a little bit of understanding of how slow ram is, how CPU caches work, how expensive allocating memory on the heap is (either, initially with something like malloc, or amortized with garbage collection) and if we stopped using languages that haven't at least built a good JIT yet, and use AOT native compilation more often, we would all be in a much happier place. Systems would be much more snappy, or we could add more features, users can run more things at once before it goes to hell, batteries would last longer.
None of this requires even changing what language you use, or massive changes in coding style. Just knowing some basic facts about how the computer works can let you choose the more efficient option among equivalently complex options -> "don't need a linked list here, let's use an array backed list instead" -> let's not use LINQ here because that allocates and this is a tight loop that runs on every request -> lets not use electron, let's build something with a similar external API that is more efficient
- seanwilson 9y agoWhy do you just assume apps using more resources now is because of coders with bad optimisation knowledge? > lets not use electron, let's build something with a similar external API that is more efficient People also choose Electron because it's an efficient in terms of development time to release apps on multiple platforms, not because they don't know how to optimise.
- bananaboy 9y agoI think that's part of the problem: people are optimising for development time and effort rather than end user experience.
- dkersten 9y agoTools like Qt+QML are, in my experience, just as efficient in terms of development time, but much more computationally and memory efficient than a typical electron application. I'm not saying that you can't make electron run efficiently, just that it takes more work and therefore since most teams optimise for development rather than computation, the end result is that electron is (again in my personal experience) typically less computationally/memory efficient. It also helps that in QML javascript is typically used only as non-performance-critical glue code and the rest (and the framework itself) is in C++ and the GUI rendering is in OpenGL.