4 ms·

Why is this on the front page? It's a well known fact and I wouldn't expect much from an alpha-stage software (premature optimization, etc.).

theCricketer 12y ago
Maybe I'm a noob, but its such a nice conversation. Real interest to improve a product. And a busy engineer taking time to help onboard the new comer to the Atom project. Pretty cool IMO.
ceejayoz 12y ago
Making it usable isn't "premature optimization".
icefox 12y ago
It really depends on your expectation. Back when I created the Arora browser (2008) one common complaint was how starting up a new browser (firefox,ie,safari) took so long so no one should have cared about the startup speed. But as a developer I cared because I was also a user and regularly kept the load time under a second and much more closer to 100ms (with Qt in memory). As you approach commodity status (like browsers were back then) load times are one of the easy things that cause you to lose users. It was a pretty basic optimization problem. Defer loading of assets that are not needed, tricks like showing something to the user even if they can't actually interact with it for another 15ms, removing expensive computation that can occur seconds/minutes later (does the disk cache really need to check for expired stuff right now on startup?) This was regularly tested with a "big data" such as a large disk cache, a history measured in years, etc. After those architectural decisions were made then it was basic profiling and fixing hotspots, improving algorithms and going beyond my application I went through and fixing issues in underlying libraries such as in Qt where I made fixes which not only improved my startup time, but every single Qt application. Startup speed matters, sometimes a lot, sometimes not so much. It is both interesting because optimizations are a common problem in our field and the different approaches that can be taken are interesting to discuss, but it is also interesting taking a look at how this particular project cares about startup speed and what they have decided to prioritize over it (the social / project management aspect).
- Cthulhu_ 12y ago
  Your post reminds me of when Chrome was first released, and how startup time (and speed in general) was one of their primary concerns. They had (and probably still have) a whole suite of performance tests that, amongst other things, measure startup time. With that in mind, if they didn't have those optimizations, Atom would probably be an order of magnitude slower to start up than it is today. It's all a matter of non-functional requirements and priorities, I guess. On the other hand: as the saying goes, "make it work, make it pretty, make it fast" - which can be interpreted in various ways, like "working software is more important than fast software" (aka avoid premature optimization), and "a well-designed application is easy to optimize".
  - chriswarbo 12y ago
    > as the saying goes, "make it work, make it pretty, make it fast" OT: I've not actually heard that stated before. I've seen "make it work, make it work correctly, (if you have the time) make it work fast" Maybe I shouldn't be allowed near front-end stuff ;)
  - HelloNurse 12y ago
    For an intensely interactive application such as a text editor, performance is part of "make it work". If the screen is lagging behind keypresses, or trivial commands (e.g. the mentioned reordering of tabs) take long enough to wonder whether the program is hung, the basic contract of user interface has been broken. Basing the core of a text editor (not only scripting, as in Emacs, but input, rendering, event handling, data structures) on low-performance technology is as wrong as, say, designing it for single-byte character sets only.
userbinator 12y ago
I think it's an interesting demonstration of the rather sad fact that despite hardware today being many, many orders of magnitude faster than what was around e.g. 2 or 3 decades ago, it seems software has only gotten increasingly inefficient, so there's a huge amount of processing power and - if humans are being kept waiting, their time - being wasted because of this; this is a text editor, albeit a featureful one, whose resource consumption is disproportionate to its capabilities. It's what happens when countless abstractions are piled upon one another, with little regard for the consequences of doing such a thing. Even Emacs is smaller, and it's just as if not more customisable/featureful. Here is a nice rebuttal to that "premature optimisation" myth: http://ubiquity.acm.org/article.cfm?id=1513451 http://ubiquity.acm.org/article.cfm?id=1513451 From personal experience, by the time a system gets too big/slow, the inefficiency is usually distributed throughout so that it becomes more difficult to single out one component that's causing it, and there is no easy way to optimise such a system short of redesigning and rewriting it - it can be said that the problem is because "the whole is bigger than the sum of its parts."
erikb 12y ago
This is a question I never understand. What ends up on the front page is no single persons decision. If enough people upvote something in a short enough time frame it will get on the front page. You know that, and you also know that it's not logical process. Thus sometimes an article ends there that might not make sense there at all.
- kachnuv_ocasek 12y ago
  Of course by "why is this on the front page?" I actually mean "why are people upvoting this?" The latter seems a bit too aggressive even for me, though.

theCricketer 12y ago

Maybe I'm a noob, but its such a nice conversation. Real interest to improve a product. And a busy engineer taking time to help onboard the new comer to the Atom project. Pretty cool IMO.

ceejayoz 12y ago

Making it usable isn't "premature optimization".

icefox 12y ago

It really depends on your expectation. Back when I created the Arora browser (2008) one common complaint was how starting up a new browser (firefox,ie,safari) took so long so no one should have cared about the startup speed. But as a developer I cared because I was also a user and regularly kept the load time under a second and much more closer to 100ms (with Qt in memory). As you approach commodity status (like browsers were back then) load times are one of the easy things that cause you to lose users. It was a pretty basic optimization problem. Defer loading of assets that are not needed, tricks like showing something to the user even if they can't actually interact with it for another 15ms, removing expensive computation that can occur seconds/minutes later (does the disk cache really need to check for expired stuff right now on startup?) This was regularly tested with a "big data" such as a large disk cache, a history measured in years, etc. After those architectural decisions were made then it was basic profiling and fixing hotspots, improving algorithms and going beyond my application I went through and fixing issues in underlying libraries such as in Qt where I made fixes which not only improved my startup time, but every single Qt application. Startup speed matters, sometimes a lot, sometimes not so much. It is both interesting because optimizations are a common problem in our field and the different approaches that can be taken are interesting to discuss, but it is also interesting taking a look at how this particular project cares about startup speed and what they have decided to prioritize over it (the social / project management aspect).

Cthulhu_ 12y ago
Your post reminds me of when Chrome was first released, and how startup time (and speed in general) was one of their primary concerns. They had (and probably still have) a whole suite of performance tests that, amongst other things, measure startup time. With that in mind, if they didn't have those optimizations, Atom would probably be an order of magnitude slower to start up than it is today. It's all a matter of non-functional requirements and priorities, I guess. On the other hand: as the saying goes, "make it work, make it pretty, make it fast" - which can be interpreted in various ways, like "working software is more important than fast software" (aka avoid premature optimization), and "a well-designed application is easy to optimize".
- chriswarbo 12y ago
  > as the saying goes, "make it work, make it pretty, make it fast" OT: I've not actually heard that stated before. I've seen "make it work, make it work correctly, (if you have the time) make it work fast" Maybe I shouldn't be allowed near front-end stuff ;)
- HelloNurse 12y ago
  For an intensely interactive application such as a text editor, performance is part of "make it work". If the screen is lagging behind keypresses, or trivial commands (e.g. the mentioned reordering of tabs) take long enough to wonder whether the program is hung, the basic contract of user interface has been broken. Basing the core of a text editor (not only scripting, as in Emacs, but input, rendering, event handling, data structures) on low-performance technology is as wrong as, say, designing it for single-byte character sets only.

userbinator 12y ago

I think it's an interesting demonstration of the rather sad fact that despite hardware today being many, many orders of magnitude faster than what was around e.g. 2 or 3 decades ago, it seems software has only gotten increasingly inefficient, so there's a huge amount of processing power and - if humans are being kept waiting, their time - being wasted because of this; this is a text editor, albeit a featureful one, whose resource consumption is disproportionate to its capabilities. It's what happens when countless abstractions are piled upon one another, with little regard for the consequences of doing such a thing. Even Emacs is smaller, and it's just as if not more customisable/featureful. Here is a nice rebuttal to that "premature optimisation" myth: http://ubiquity.acm.org/article.cfm?id=1513451 http://ubiquity.acm.org/article.cfm?id=1513451 From personal experience, by the time a system gets too big/slow, the inefficiency is usually distributed throughout so that it becomes more difficult to single out one component that's causing it, and there is no easy way to optimise such a system short of redesigning and rewriting it - it can be said that the problem is because "the whole is bigger than the sum of its parts."

erikb 12y ago

This is a question I never understand. What ends up on the front page is no single persons decision. If enough people upvote something in a short enough time frame it will get on the front page. You know that, and you also know that it's not logical process. Thus sometimes an article ends there that might not make sense there at all.

kachnuv_ocasek 12y ago
Of course by "why is this on the front page?" I actually mean "why are people upvoting this?" The latter seems a bit too aggressive even for me, though.