3 ms·
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)
by 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 agoYour 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 agoFor 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.