3 ms·

Now that we do have the hindsight of experience, and it is time to make that decision again, why are the maintainers going with the clearly smellier approach?

by sooheon 10y ago

jeremiep 10y ago
Because even with experience you don't refactor a 40+ years old piece of software easily without breaking half the ecosystem. I'm sure there's a whole world of tradeoffs we're not seeing that the maintainers have to deal with.
MBCook 10y ago
They have an immediate problem (things are slow/broken on newer glibc) that needs fixing. Someone has posted sane code to fix the issue in a similar fashion to what they were doing before but without needing to reach into the memory manager. The maintainer who is mad wants it fixed right (replace the whole thing and make the elisp load fast) but so far neither they nor anyone else seems to have posted code to do that. Bird in the hand. I would hope they'd just remove the need for the mechanism totally in the future, but for now.... bird in the hand.
- btilly 10y ago
  What would fixing it right look like? Make elisp faster. Easier said than done. Any easy wins already happened. Introduce various lazy loading mechanisms and switch to that by default. That doesn't help any third party plugins that people might use. In fact any such work could create ways of breaking the expectations of said plugins! Identify/eliminate work spent on dead code paths in initial load. Again, easier said than done. And there are bound to be a lot of, "I don't see what that is useful for, but what third party plugins might need it?" In the meantime, end users faced with the choice of a slow new release versus a fast old one, will resist upgrading. And if there is a patch that simply makes things fast, that is generally acceptable. The current moment provides pressure to do things right. If the cheap fix is taken, there are no guarantees on when there will be another opportunity like this one. But pressures exist to take the easy out right now. And if taken, it won't be easier next time either.
  - chris_wot 10y ago
    I'm amazed that Chrome and Firefox load instantly and they regularly interpret scads of DOM input and complex JavaScript code. Exactly why can't emacs do this again?
    - db48x 10y ago
      The first time you start Firefox, it reads in a whole mess of xul, html, css, and javascript. It parses it all and then dumps it to a binary file that can just be mmap'd back in next time. This is exactly like emacs, except that emacs also dumps out all of its own internal state including the state of the allocator; that makes it more fragile.
armitron 10y ago
It's not smellier, it's actually a great feature. Dumping your own images will be extremely useful to many Emacs users.

Now that we do have the hindsight of experience, and it is time to make that decision again, why are the maintainers going with the clearly smellier approach?

by sooheon 10y ago

Now that we do have the hindsight of experience, and it is time to make that decision again, why are the maintainers going with the clearly smellier approach?

jeremiep 10y ago

Because even with experience you don't refactor a 40+ years old piece of software easily without breaking half the ecosystem. I'm sure there's a whole world of tradeoffs we're not seeing that the maintainers have to deal with.

MBCook 10y ago

They have an immediate problem (things are slow/broken on newer glibc) that needs fixing. Someone has posted sane code to fix the issue in a similar fashion to what they were doing before but without needing to reach into the memory manager. The maintainer who is mad wants it fixed right (replace the whole thing and make the elisp load fast) but so far neither they nor anyone else seems to have posted code to do that. Bird in the hand. I would hope they'd just remove the need for the mechanism totally in the future, but for now.... bird in the hand.

btilly 10y ago
What would fixing it right look like? Make elisp faster. Easier said than done. Any easy wins already happened. Introduce various lazy loading mechanisms and switch to that by default. That doesn't help any third party plugins that people might use. In fact any such work could create ways of breaking the expectations of said plugins! Identify/eliminate work spent on dead code paths in initial load. Again, easier said than done. And there are bound to be a lot of, "I don't see what that is useful for, but what third party plugins might need it?" In the meantime, end users faced with the choice of a slow new release versus a fast old one, will resist upgrading. And if there is a patch that simply makes things fast, that is generally acceptable. The current moment provides pressure to do things right. If the cheap fix is taken, there are no guarantees on when there will be another opportunity like this one. But pressures exist to take the easy out right now. And if taken, it won't be easier next time either.
- chris_wot 10y ago
  I'm amazed that Chrome and Firefox load instantly and they regularly interpret scads of DOM input and complex JavaScript code. Exactly why can't emacs do this again?
  - db48x 10y ago
    The first time you start Firefox, it reads in a whole mess of xul, html, css, and javascript. It parses it all and then dumps it to a binary file that can just be mmap'd back in next time. This is exactly like emacs, except that emacs also dumps out all of its own internal state including the state of the allocator; that makes it more fragile.

armitron 10y ago

It's not smellier, it's actually a great feature. Dumping your own images will be extremely useful to many Emacs users.