14 ms·

These are called opportunities

321 points by pmarin 6y ago

gjs278 6y ago
php sites get replaced by nodejs sites that use 3x the resources and eventually crash or cause problems in the client's browser due to a socket issue.
routerl 6y ago
"Software is getting slower more rapidly than hardware is becoming faster" https://en.wikipedia.org/wiki/Wirth%27s_law https://en.wikipedia.org/wiki/Wirth%27s_law
- TwoBit 6y ago
  I don't think this is mostly true. Many classes of applications are running perceptively similar to before but accomplishing much more. Easiest example is game software. But it’s true enough for web browser software if you can extract the crippling effect of today's ad networks (which many people do via a plugin).
  - ryandrake 6y ago
    Are they really accomplishing that much more? Or are they being used to create and destroy containers of ClassFactoryProxyBuilders over and over? The topic reminds me of “24 Core CPU and I Can’t Move My Mouse” [1]. We deploy faster and faster hardware and use it for what? For holding global locks, iterating through object tables and navigating through abstraction after abstraction until the call stack is 100 calls deep. My word processor today is about as UI responsive as MS Word was in the 90’s and I use pretty much the same features now as I did before. Visual Studio Code’s UI is noticeably slower on my modern CPU than Visual C++ 6 was 30 years ago, although to be fair it compiles much faster today. 1: https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/ https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and...
    - outsomnia 6y ago
      > abstraction after abstraction until the call stack is 100 calls deep. If the software is maintainable and has less bugs, this is not a crazy way to spend the cycles. Web browsers run insanely stable over very long periods of time when you consider what's under to hood.
      - lmm 6y ago
        Yep. Remember how often Word would crash in the '90s? We were warned to save our work regularly lest it be lost. Make it work, then make it right, then make it fast. We shouldn't even begin to worry about performance until we've got a handle on correctness, and frankly software in general isn't there yet.
        TeMPOraL 6y ago
        That's nice in the abstract, but in real life, shitty performance costs people money and sanity right now, and that cost scales up with the number of users. Also, arguably, auto-saving existed in 90s - and the primary reasons it wasn't as nice as it was today were UX (wasn't enabled by default IIRC) and hardware (spinning rust wasn't good enough to support transparent auto-saving every other second).
        lmm 6y ago
        > That's nice in the abstract, but in real life, shitty performance costs people money and sanity right now, and that cost scales up with the number of users. So do crashes, and so especially does silently outputting the wrong answer. Slow but reliable beats fast but flaky every time, and it's much easier to speed up a working program than fix a flaky one.
      - TeMPOraL 6y ago
        > If the software is maintainable and has less bugs, this is not a crazy way to spend the cycles. It's not? Consider: to make your workflow easier, you impose costs - real costs, in both emotions and money - on every single one of your users. And the more users you gain, the more the society ultimately pays for a fixed benefit of making it easier for your team to do the work. To some degree, this trade-off is necessary, but I propose that it's absolutely crazy to consider taking it unless it is necessary.
  - Tepix 6y ago
    > ... but accomplishing much more. Easiest example is game software. Ha! Are you saying the old games that ran faster didn't bring us joy?
    - maccard 6y ago
      I think that's a really disingenuous reply. He's clearly saying that the processing power advancements have shown significantly in games;commodity hardware now performs real time ray tracing in 3d in a photorealistic depiction of a real life city for not-much-more-dollar-cost than the N64 did when it was launched 25 years ago. Whether it brings you more joy or is more/less fun is irrelevant
      - Tepix 6y ago
        It was a tongue-in-cheek reply of course, but there's some truths to it. Just like 4K resolution doesn't make movies better, adding raytracing or fancy shadows doesn't turn a bad game into something that's more fun than, say the Super Mario Bros. (1985, 31KByte) on NES (2KB RAM) which sold 40 million copies. We need to question ourselves every now and then why we are adding things like cutting edge graphics to games (and adding complexity in general). Which is what this article is about.
  - TeMPOraL 6y ago
    That's nice that you mention games, because they're a great baseline for what your hardware can do. I personally use it as a sanity check. I look at the amount of data processing the software I'm building does, compare it mentally against the amount of data processing a random videogame from 10 years ago did, and ask myself (and the team), how come our software does much less work than that game, and runs much slower than that game did a decade ago? (And the answer very often boils down to: lots of unnecessary parsing or string processing, and bad choices in data structures. Both relatively easily fixable, if one bothers to look for it - and both mistakes that could have been avoided in the first place at little to no cost in developer effort.)
- lpa22 6y ago
  With as recent of a phenomenon as bloated software feels, I was shocked to see the 1995 date on this quote
  - ainar-g 6y ago
    Niklaus Wirth is a visionary, and his legacy is honestly severely underappreciated. Pascal was a reasonably well designed language for its time and purpose. The Oberon ecosystem has in many ways inspired Plan 9 From Bell Labs and, transitively, the whole post-Unix movement. His book “Compiler Construction” is still one of the most accessible introductions into the world of compilers, which I recommend to anyone interested in the topic.
- taneq 6y ago
  Try using a 20-year-old machine, even a freshly installed machine running contemporaneous software is painfully slow compared to a modern econobox.
  - brazzy 6y ago
    I have a desktop PC that I built from cheap components 10 years ago (first generation core i3). It doesn't feel particularly slow at all using most current software.
    - sumtechguy 6y ago
      You may just be used to it? I just did an upgrade this year to something way more current. Using my old computer feels 'sluggish'. Last year this time I would have said the same as you about that same computer. The new computer is from cold power off to useable desktop in under 5-10 seconds. The old one was more like 60. If the computer is serving your needs then there is no issue really. For me it was some new bits of software just did not cut it on the old one.
      - brazzy 6y ago
        No, I have my pretty new work laptop as a comparison. Maybe I'm just not using any really resource-hungry new software.
  - pjmlp 6y ago
    No need for contemporaneous software, for many people a 20-year-old office of some kind is more than enough, plus email. :)
  - AnIdiotOnTheNet 6y ago
    I have an old XP laptop in my office, which I keep around because it still has a serial port. Every couple of months I have to use it and I'm always a bit unsettled at first by how responsive everything is because modern software has made me so use to everything feeling like molasses.
etaioinshrdlu 6y ago
Maybe Apple could use their walled garden to tax developers based on the amount of resources their app uses. You need $100 to put your App in the store; you need to pay $1000 to use more than 10% of CPU performance; you need to pay $10000 to have an app bundle more than 10MB; and so on -- charging ridiculous amounts for access to high-performance battery-draining features. For dealing with app developers with deep pockets like Google -- you could charge the developer something egregious like $10 per install. At some point the screws are tight enough that you just build your app to behave better. It would be absolutely dastardly -- but could actually have the effect of forcing app developers to care about performance :) They won't care unless they have to. Web developers have to care about performance because of SEO (and click metrics...) but it only goes so far because it's not forced. I disagree completely with the walled garden model of iOS (and the direction of macOS) but, if it nonetheless exists, I'd like to see them do something hardcore like this. The performance and battery gains would be out of this world.
- gear54rus 6y ago
  Yeah because you will be the one deciding what's normal for a given piece of software... If someone implements that bs policy it surely would be apple.
- annilt 6y ago
  Search engines should punish slow/big/bloated websites or promote light ones. Is google doing something for that? It is so annoying to spend time on web nowadays. I find myself skipping search results when website looks bloated to me. So it is like ‘search something, quickly look at results, try to click on most accurate and lightweight looking link, if website is actually bloated click back without waiting it to be fully loaded and try again on another link.’
  - etaioinshrdlu 6y ago
    Google definitely uses pagespeed as a major factor. They may also with AMP although that may be changing. They could do more though.
- 6y ago
vosper 6y ago
> It is normal that doing more takes more resources. Modern raytracers require more processing power because they generate better images. Likewise, compilers of 2020 have awesome static code analyzer which they did not have in 2009. > But doing the same thing should never become slower. Starting up an application should never take longer than it used to. If a feature is going to cost start-up time, I would rather not have it. No feature, no matter how great, could ever justify a slowdown to start-up time? That seems like an absurd position to take. Also, if you read the link to the “law” about software taking up more compute resources over time, you’ll find that the origin is Intel’s Andy Grove complaining that Microsoft wasn’t taking advantage of newer, more powerful chips. Also the title is just kind of rude and dismissive to software engineers - it’s not true that noone at all cares about performance.
- astrange 6y ago
  > No feature, no matter how great, could ever justify a slowdown to start-up time? That seems like an absurd position to take. This is actually the WebKit project's policy. Performance regressions are not allowed and you can't commit any without adding an equivalent progression.
- pmarin 6y ago
  Just to be clear. I am the OP. the real title is "These are called opportunities". I used one of his cites [1] as title because the original was not catchy enough. The article was submitted a couple of times with 0 upvotes [2]. The big apple logo doesn't help either. [1] https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law [2] https://hn.algolia.com/?q=https%3A%2F%2Ffabiensanglard.net%2Fsilicone%2F https://hn.algolia.com/?q=https%3A%2F%2Ffabiensanglard.net%2...
  - vosper 6y ago
    So... you editorialized the title in order to get some traction? I hate to be that guy, but the HN guidelines ask not to do that > please use the original title, unless it is misleading or linkbait; don't editorialize I should have checked the real article title, it’s much more reasonable. I see that it has been changed here, now.
razorunreal 6y ago
If companies like Apple didn't try to make things as incompatible as possible, maybe software engineers wouldn't have to keep adding new layers of abstraction and things would run a bit faster. There's basically a never ending war between platform developers trying to create lock-in and app developers trying to escape with new cross-platform technologies.
- tgv 6y ago
  That's unfair in this context: Apple has been using the most mainstream desktop/laptop/server CPU architecture there was (and still is using it in certain models), and their new processor is ARM, which may be the most ubiquitous architecture at the moment. They're doing nothing that requires adding new layers of abstraction for normal software engineering.
  - est31 6y ago
    I agree with you on the processor part, but them using Metal instead of Vulkan while deprecating OpenGL doesn't really help game engine developers who want their code to run on Android, Apple, Windows (and maybe Linux) devices.
    - nlitened 6y ago
      If I remember correctly, Metal predates Vulkan, so the argument could be vice versa :)
remolacha 6y ago
In many circumstances, it’s better to optimize for developer time over compute time. I’m glad that I can choose from zillions of (slower than necessary) web/electron apps instead of a smaller number of “optimized” apps written by “real engineers”.
- tgv 6y ago
  As hinted at in the article, that becomes technical debt that can be really difficult to get rid of later. Of course, optimizing may create another kind of debt, but that Firefox has lost the race from a very convenient lead is telling. Ideally (IMO), if you want to optimize development time, also consider future development time.
  - arvinsim 6y ago
    Technical debt means guaranteed work in the future for software developers. I only say this half-jokingly.
    - astrange 6y ago
      The problem is that it gets exponentially harder to fix something the later you do it. Even if you wait a few years it could be easier to rewrite from scratch than fix a large bug. Btw, people bring up a features vs. speed tradeoff here and I don't think it's true - in my experience perf issues come from stupid random bugs more often than they're fundamental parts of new features. There is definitely a development time vs speed tradeoff, though; the best way to save time here is to have really good regression tests.
- tonyedgecombe 6y ago
  I don't know if we have optimised developer time either. I'm certainly slower when doing anything on the web than I was with VB6.
  - jbverschoor 6y ago
    People like to think they're smart. Being able to use complex things makes you look smart. Creating a complex system makes you look even smarter.
tasty_freeze 6y ago
The author says that he switched to Chrome and never looked back because when it came out, it booted up in under a second. > Firefox developers famously attempted to fix the five second startup time in 2010 via bug #627591[6]. They fixed many issues but not enough to warrant a second try. It would be a great point if Chrome still started up in under one second. In one data point, there isn't much difference. Plus I typically (re)launch the browser less than once per day. The time difference on start up isn't the deciding issue for me.
- TwoBit 6y ago
  I've never understood the launch value. You start an app once a day - or in my case once a week - and run it for hours thereafter. He should have talked about Chrome's speed, which was significantly faster ten years ago, though not enough now for me to care.
  - vosper 6y ago
    You’re right - one of the great unheralded achievements of modern computing is that most people can run all the applications they need (of which there are more, all of them more powerful than ever before), all at the same time, on a middle of the road laptop, and never have to think about it. You launch them once, when your computer starts, and that’s it. Office, Excel, Figma, 5 other web-apps, Slack, 30+ websites, Spotify - no problem.
  - annilt 6y ago
    He uses Chrome as an example. You can think of a website instead of it, its ‘start up’ time always matters and almost all websites are slower than 10 years ago
  - meheleventyone 6y ago
    Depends on the usecase but we find Chrome to be significantly faster than Firefox in JS performance.
- bryanrasmussen 6y ago
  >The author says that he switched to Chrome and never looked back because when it came out, it booted up in under a second. perhaps this can be taken as a claim to being a typical consumer, as they are often described as not especially rational. (the never looking back part)
PradeetPatel 6y ago
With the modern cloud computing paradigm, it's a lot easier to produce code and let it scale horizontally than to write optimised code, thus speeding up the delivery cycle.
ensiferum 6y ago
People want more behavior and more data. more data needs Better algorithms for processing and it's very easy to fall off the performance cliff with a bad algo that doesn't scale well. Add multiple layers and it's not always obvious what the total complexity is.
saagarjha 6y ago
I’m not sure if this qualifies as an “unpopular opinion”, but I get a predictable amount of flak whenever I bring it up: I think the assumption that a company should outfit their developers with “the best” machines is problematic. If my company could give me a brand new 13” MacBook Pro from a couple years ago, I’d take it over the 16” 2020 model I have. To many the hardware a company gets its engineers is some sort of inviolable measure of how much they love you, and a company that doesn’t buy you the beefy model of the latest laptop is clearly a horrible place to work. But personally I tend to use moderately old hardware and then upgrade every once in a while to the latest model, and every time I’m always interested to see how some software can go from being utterly unusable to “reasonable”. I read articles about how Discord made their app’s scrolling 60 FPS and I go “yeah, right” because my iPhone SE gets nowhere near that…but on my iPhone 12 mini it kind of actually does. Trying to run any sort of Swift Playgrounds or previewing on my Early 2015 MacBook Pro is an exercise in frustration…but throw two extra cores at it and give the process a couple more gigabytes of RAM and it’s usable. It’s clear that all of these things never get tested beyond the high-powered machine that the developer used. And I don’t see the trend of developers being completely out of touch of what devices their users are using going away anytime soon. But maybe we should start considering “experience correction” tools as part of a regular testing methodology. A friend of mine once lamented that the web would be a much better place if opening the Chrome developer tools automatically enabled the network throttler, and I think I’d have to agree with him.
- arcticbull 6y ago
  Your job is to make money for the company. Your job isn't to build the smoothest, most optimized, experience for your customers. It's to build features customers want or need, which in turn create value for your employer. This generated value pays your paycheck. Of course if you do a bad enough job, it's counterproductive, but to the extent it's not bad enough your job is to focus on features and development and not on optimization. Once performance is bad enough, your job becomes optimization -- via instrumentation, measurement and profiling. Every minute you spend waiting on a build or waiting for an app to launch or waiting for some long-running task to finish is a minute you're not creating value. Compounding this problem, it impacts morale if you spend your day looking at spinning beach balls while your boss won't get off your back about when you'll be done. This is your employer's perspective, more than likely. [edit] Another way of looking at this is to say that you and your customers are doing different jobs. You have all the extra cpu and memory overhead of developing a product — all they have to do is run it. By definition your workload is more demanding.
pfranz 6y ago
Browsers seem to be one of the few apps where they compete on speed. I remember Firefox was peeled out from the Mozilla browser and liking it because it was much faster and lighter. Similar to the quote about Chrome in the article, speed came up quite a bit when Safari was developed almost a decade before Chrome. > The number one goal for developing Safari was to create the fastest web browser on Mac OS X. When we were evaluating technologies over a year ago, KHTML and KJS stood out. [1] > Don Melton: That's just perfect for me. In another life, I was a QA engineer. I run the tests, and if I detected we were slower, I closed the tree. That was the beginning of my policy, that policy that I pulled out of my hiney. Boy, talk about making yourself popular on your team doing that! [2] (on his no regressions policy) [1] https://marc.info/?l=kfm-devel&m=104197092318639&w=2 https://marc.info/?l=kfm-devel&m=104197092318639&w=2 [2] https://www.imore.com/debug-111-don-melton-blink-servo-and-more https://www.imore.com/debug-111-don-melton-blink-servo-and-m...
jasonhansel 6y ago
This seems like a case of the Jevons Paradox, where the "resource" is CPU cycles: https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox
- epicureanideal 6y ago
  I wonder if this can be applied to the labor market? As technology makes workers more efficient, demand actually increases? Or for example, software engineers. As software becomes cheaper to produce, demand for it increases?
  - sleepy_keita 6y ago
    Parkinson's law https://en.wikipedia.org/wiki/Parkinson%27s_law https://en.wikipedia.org/wiki/Parkinson%27s_law
brundolf 6y ago
> But doing the same thing should never become slower But none of the described software is doing the same thing it was before. This author is saying "well, you know, it's still a photo editor, same thing" and "well, you know, it's still a web browser, same thing". But those are gross oversimplifications of how a major piece of software evolves over the course of a decade.
- saagarjha 6y ago
  Perhaps, but when people are using the software in the limited capacity it would still be nice to have the "old" performance. I think people would be far more forgiving of Slack's performance problems, for example, if sending a simple text message didn't require as much RAM as a video call, or their IDE's performance if typing was as smooth as it is in vim but the complicated analysis stuff took a little longer to come in.
- annilt 6y ago
  Problem is these softwares can be made as fast as they were before but instead of investing time on performance/resource usage, developers see more value on extra features. So you end up with a fully featured but slower than ideal software. Even it is slower, still in acceptable limits to the majority of users.
  - arvinsim 6y ago
    > developers see more value on extra features. Yet another post blaming developers when it's the product managers and business development people that decide the direction of the product.
    - annilt 6y ago
      I’m not blaming developers. Indeed extra features are more valuable(for users/marketing etc.) than performance most of the time. So, it’s completely normal. More hardware will lead to more features and bloat. There is no one to blame on that.
    - izacus 6y ago
mullingitover 6y ago
It's a pretty straightforward law of physics: software is a gas that expands to fill its container.
__MatrixMan__ 6y ago
I'm under the impression that you can run pretty much anything in web assembly, which is like a whole tiramisu of abstraction above the hardware. Not sure how many more cycles that ads but I bet it's quite a few. Is it possible that we're inventing all this encapsulation because we think we can escape an ugly truth at a higher layer? Is it possible that we're wrong about that?
- timdaub 6y ago
  Yes and no. WebAssembly itself has no IO except for its linear memory. So many programs will then have to have a component in a system-native language (e.g. to write files). So technically I'm not sure how much you can abstract away for performance.
- 3pt14159 6y ago
  It's about security and ease. If it were secure to install arbitrary code on a computer, we'd have more apps. If it were easy to compile across platforms and handle every weird OS call, we'd have way, way more apps. Browsers are essentially a translation layer with some security guarantees and even there, on both counts they aren't perfect. They're merely better than the alternative. If you ever want to disrupt the entire industry, make something that is easier to code for and more secure than a web browser. If it's faster too, then that's gravy.
txdv 6y ago
Part of the problem is that software engineering time is more expensive than just buying better hardware or letting the end user deal with the slow software. So business just buy better available hardware rather than spending time optimizing and end user want usually the cheapest product. There are only a few organizations like Sublime HQ who focus on fast software. But they are producing niche products, catering to other software developers who appreciate the fast nature of their software and have the money to spend on it. I personally bought Sublime Merge and my IT friends who make a lot of money are perplexed by my decision spending 100 on an amazing development tool. I also sometimes dream with my programming buddy about creating a company which creates fast software like Sublime HQ, but it is really hard to sell this kind of software.
- est31 6y ago
  It depends on the number of users. If say Slack got 10% faster, it'd deliver tremendous productivity increases for customers all around the world. So in theory, there is a large incentive here, and Slack can absolutely capture a part of the value they'd be creating from doing such a speedup. But Slack is a product with many users. Speeding up highly specialized products that have maybe 100 users doesn't create as much value.
  - txdv 6y ago
    If you reach Facebook scale and optimize a flow by 10%, you can basically save thousands of dollars per month making optimizations valuable for the company again. This is one of the aspects where optimizations starts making sense again.
    - tonyedgecombe 6y ago
      The trouble with Facebook is the obvious optimisation for them is to offload work from their servers to my device. Hence we get bloated clients.
      - txdv 6y ago
boberoni 6y ago
> If a feature is going to cost start-up time, I would rather not have it. Is it that we don't care about start-up time? Or is it that we don't have the choice? We still care about start-up time, but there's diminishing returns to this sort of optimization. Moreover, the developer teams have to balance these factors with a variety of other product features and with optimizations for developer productivity. Gains in hardware performance might be wasted by slow software, but "fast software" can certainly reap the benefits. By "fast software", I mean computation heavy workloads like ML training, image processing, etc. The article touches on this. > But doing the same thing should never become slower. Starting up an application should never take longer than it used to. I would not consider starting up Xcode in 2008 and starting up Xcode in 2020 to be "doing the same thing". Through many years of updates, this application has become very different. I personally don't use Xcode, but I would hope that Xcode 2020 has more features than Xcode 2008. Now, whether Xcode 2020 actually NEEDS all those new features is a different questions, especially if it comes at a cost to start-up time. As individual users, it may feel like we have no choice in these decisions. However, the optimist in me wants to think that we DO have a choice. We can still "vote with our behavior". If Xcode is too slow, users will stop using it and prefer alternatives that provide the performance that we want. However, if users continue to use Xcode in spite of slow start-up time, then perhaps there's something more important that's keeping users around.
- flohofwoe 6y ago
  > but I would hope that Xcode 2020 has more features than Xcode 2008. No, not really, and definitely none that need to be initialized at application startup. There are some truly baffling performance regressions in Xcode over the last years. Like starting for the first time into the debugger taking almost half a minute. > If Xcode is too slow, users will stop using it and prefer alternatives that provide the performance that we want. There are no alternatives if you want to build iOS applications. You'll at least need to use the Xcode command line tools for this, and some of the performance problems (like the slow start into the debugger) seem to be rooted there, because VSCode has the same problem.
tjansen 6y ago
There is an easy explanation for this: developers optimize their code when the product owner tells them to spend time on this. The product owner will tell them to optimize when product owner notices that the software is getting too slow. When new hardware is released, slowdowns that would be visible on older hardware won't be easily noticeable, so programmers will work on other features rather than optimizing code. Until the code becomes too slow to run on current hardware, then they work until it becomes usable again.
- tsjq 6y ago
  Totally this
- AmericanChopper 6y ago
  The thing hardware engineers are missing here is that people don’t want to use their improvements to improve speed. They want to use them to pay for more expensive abstractions that allow them to develop software faster. Unless you have a performance issue that’s really pathological, speed really doesn’t matter for most applications. I’ve developed dozens of python web applications. Python is slow as hell, but I can count on one hand the number of times hand where I found the RoI of optimizing a performance issue to be more valuable than feature development (and all of them were problems that couldn’t be solved with more hardware, which is the default best-RoI way to approach most performance issues).
  - nitrogen 6y ago
    I think distinguishing between client-side and server-side speed matters. Python and Ruby are fast enough, and as you say you can scale them horizontally for a long time before it gets cheaper to optimize or rewrite in another language. But if a UI is slow, that does matter. Delayed keypresses, unacknowledged but registered interactions, or the worst, delayed layout changes, are completely flow breaking.
    - AmericanChopper 6y ago
      I think my rationale applies to client side code too, just in a slightly different way. It is so easy to write performant browser UIs these days, and a lot of that is down to these same sorts of hardware improvements (as well as V8 improvements). Even bloated web app front ends will perform very well most of the time. You can take that to the extreme of course, but you really have to go out of your way to do it. I’ve built frontends before without giving any consideration at all to performance, and they’ve always performed perfectly well. Websites like cnn.com exist, so it is demonstrably possibly to do it badly, but you have to stray so far from the light accomplish something like that.
cosmotic 6y ago
New shiny libraries, frameworks, and platforms draw in developers. Those new things are typically not well polished or optimized. By the time they get optimized, developers move on to newer and shinier things. Java, PHP, .NET, and Javascript were all slow until they got fast (although with Javascript, things got really complicated and slow again). I say this as a developer that uses all those now-fast things and avoids the shiny and new for these reasons (and more, including lack of tooling).
- Cthulhu_ 6y ago
  But you'd think those new things would be built on top of the older, faster, 'core' libraries, and the abstraction only improves developer ergonomics while the result is just as fast if not faster. I mean compilers should empower that, allowing for good, readable code that compiles to blazing fast code. That's the theory anyway, but I know in practice it's different. I keep thinking of my time working on iOS software, where I experienced the transition from objective-C to ARC to Swift; it still felt like the end result was the same, if not even better (Swift whole-module optimization), but the developer ergonomics were much improved. Still kinda miss xcode, a shame it's not really usable for anything that isn't obj-C/Swift.
bjarneh 6y ago
> Chrome also had these. But when I saw it boot nearly instantly instead of the five seconds it took to Firefox, I immediately switched and never looked back. It really was incredible how fast Chrome seemed when it first came out; and not just in terms of startup speed; rendering speed was superb compared to the competition. Now Firefox seems much closer to Chrome in terms of rendering speed, and for certain web-pages (some company web-pages with huge tables at least) Firefox renders them noticeably faster.
- jlokier 6y ago
  For WebAssembly, Firefox starts some things a lot faster. I was using the WASM version of Microsoft Z3 recently (a kind of theorem prover), and it took about 15 seconds to start in Chrome, and about 2 to start in Firefox on the same machine. It ran a bit faster in Chrome after that, but not noticeably. Startup time was a bottleneck. Imagine visiting a web app then waiting 15 seconds while it's frozen before the functionality starts working.
  - bjarneh 6y ago
    > Microsoft Z3 recently (a kind of theorem prover) Also a theorem prover with kinds (or more one type of elements), if I'm not mistaken :-) Firefox is getting really good; perhaps a bit memory hungry, but that's hardly where Chrome shines either...
    - jlokier 6y ago
      They call them sorts not kinds :-) "Sort" comes from many-sorted logic where the sort distinction is at the syntactic level, so easily inferred. They are not called "types" because they don't come from type theory; there is no logical richness to the relationships between different sorts, unlike the relationships between types. They are not called "kinds" because that is the name of a higher-order concept in type theory.
eb0la 6y ago
I remember spending two days hunting a bug in my Turbo Pascal code when I upgraded from a 286 machine (12Mhz) to my a Pentium-66. It was a while loop with one extra zero at the end. The loop with the bug run in twos second in the 286. Easy to notice. In the Pentium it didn't run in the blink of an eye. This way of benchmarking performance, with human wall clock time, makes performance problems add up: They add up faster, the faster your development machine is. I guess a good benchmarck would be number of cycles run; but if the software runs fast enough it's hard to justify working more time on it unless there a business need to do it faster (like you're billed by milisecond, by intruction run like in a blockchain, or it is part of the core layer of your product and performance matters to capture market share).
system2 6y ago
98% better than any laptop out there or the ones released in 2020? My windows laptop is already better than 90% of the laptops out there.
throwitaway1235 6y ago
Uninitiated, outsider, novice etc question in relation to the topic - is there a reason banking websites are a bloated nightmare to navigate, regardless of my devices capabilities? Chase is the worst. So slow I've missed credit card payments over it.
- high_priest 6y ago
  I've been in contract with the leading bank in my country ever since they introduced their "online focused" branch and never had any issues nor have I directly paid for any of the provided services. Now, every time I saw someone work through software of some other bank, it was an atrocious experience. So, look into the offer of the largest bank in your country. It's most often the main bank in your country. If they promise to not bill you for the services you need, there is nothing to lose from switching to them.
  - throwitaway1235 6y ago
    Thank you.
4778468d 6y ago
I’d love a new Mac mini but 16GB of RAM just doesn’t cut it any more. If it was 32GB I’d buy. But a fast CPU is only marginally useful when my machine grinds from memory swapping.
0898 6y ago
Is there a Wordpress theme that will make my website look like OP's?
pragnesh 6y ago
I think firefox is again faster and leaner compare to chrome.
baxtr 6y ago
> We carefully monitor startup performance using an automated test that runs for almost every change to the code. This test was created very early in the project, when Google Chrome did almost nothing, and we have always followed a very simple rule: This test can never get any slower. That's actually very similar to how Safari was built. After Steve showed the Safari icon, he clicked to the next slide. It had a single word: Why? Steve felt the need to say why Apple had made its own browser, and his explanation led with speed. Some may have thought that touting Safari performance was just marketing, a retrospective cherry-picking of one browser attribute that just happened to turn out well. I knew better. I had been part of the team that had received the speed mandate months earlier, and I had participated in the actions he now described which ensured the speed of our browser." [1] [1] Kocienda, Ken. Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs
- ksec 6y ago
  And Safari Story from Don Melton https://donmelton.com/2013/01/10/safari-is-released-to-the-world/ https://donmelton.com/2013/01/10/safari-is-released-to-the-w...
- westwing 6y ago
  Safari may be fast, especially on mobile, but it sure is holding back everyone on features. The irony is that with WebGL2 and WASM, near-native-speed applications would be possible. Also, if there were Safari APIs for all their fancy chip features, developers might actually use them widely. The problem is that if this happened, Apple would lose its monopoly on a good app experience. They need web technology to be crappy, and poor performance is part of that picture.
  - nlitened 6y ago
    You're not talking about developers in general, you're talking about web developers—and holding them back a little is almost a positive thing to do at this point.
    - westwing 6y ago
jpgvm 6y ago
Personally I couldn't give a shit about startup time. I start most of my apps when I boot my machine and I rarely if ever close any of them or turn my machine off. I care about how fast said applications do their job, that they remain responsive and don't suffer from instability. Maybe I am just old/desktop user. My machine is a 9900K + 32GB RAM which is definitely fast but it's not absurd. With this amount of RAM I never feel the need to close anything other than to tidy up my list of open tabs so I can see the icons without scrolling again.
- ShroudedNight 6y ago
  > My machine is a 9900K + 32GB RAM which is definitely fast but it's not absurd. The 9900k appears to have similar compute throughput to a Top 500 supercomputer from 2004, a time when my Northwood P4 with 512MB RAM, and Radeon 8500 were quite comfortable running Firefox at 1600x1200 @ 85hz. A 9900K + 32G quite frankly represents an embarrassment of computing riches and the marginal improvements in end-user experience since then (mostly in the form of additional screen real estate) betray just how little we've done with that compute that truly benefits the user.
_0o6v 6y ago
> Is it that we don't care about start-up time? Not particularly. If it takes 13s to load Photoshop once a day, then I can access all these great features, that's alright with me.
pbadenski 6y ago
The test that never can get slower - I'm curious how they do it.. In my experience tracking performance regressions is much bigger challenge than solving performance issues.
zuhayeer 6y ago
“For every cycle a hardware engineer saves, a software engineer will add two instructions” To save dev time, people are no longer building native. And that bloat keeps adding up, masquerading as abstraction
ChrisMarshallNY 6y ago
I write native code, in Swift; using the built-in APIs. I also will require iOS 13 or greater in new apps (probably 14, for the ones I think may take many months before release). I try to use fairly modern techniques and patterns in my development (but I am not yet satisfied that SwiftUI is up to the task for my more complex work). It is my hope that this means that my apps will be as performant as possible. I may get an M1 Mini, as a test device, sooner or later. There’s no hurry. I am still planning on waiting for the M2 processors before upgrading most of my systems. By then, I think that most apps will have sorted themselves out.
barrenko 6y ago
To borrow a reference from Alex Crompton, building software is both "Math hard" and "Bodybuilding" hard. Coding itself is then recursively "Math" hard and "Bodybuilding" hard. Math hard is when to get something to work it's really hard "mentally" to achieve/produce/figure out, but when it works it's not a problem anymore and you can explain it to kids (like Pythagorean theorem). Bodybuilding hard is when there is clear and simple "process" to achieve a thing, but it's really hard to stick to it, because to not do so is way easier. In coding e.g, it's boring to refactor and optimize code and not put all stuff in one place and write shitty functions. In actual software development/management (one level "above") it seems it's really really hard for the team/company/PM/CEO to fight bloat. It's hard not to go for building new stuff and adding features. There is nothing to talk about and waste meetings on and add administrative and marketing staff early on if you're not working to "add new features". Mainly because there is no definable primary feature, no actual purpose for the software, no really good coders, and in 99% of cases no actual product and / or underlying business.
- ritchiea 6y ago
  Beyond it being "hard" to fight bloat, it's against the individual interests of most of the company. Let's say you have a job at Google or company X or wherever, you're a PM/dev/designer/manager/productGuy. You don't get promotions and earn more responsibility for saying "we don't need that feature." You get promotions for that cool new thing you shipped and hey if it ruins the UX or slows the app down or whatever, who cares if it's UX or your career what do you care about UX your career is dependent on MORE bloat. Incentives are totally misaligned but I can't imagine the situation will change anytime soon.
  - marcus_holmes 6y ago
    This. Also, feature design is "playtime" for most founders/devs/designers/productGuys/managers. Thinking up cool new stuff that your product can do is fun. And, once thought up, it's hard to put that feature aside. "Wouldn't it be cool if it did this..." is easy and fun. Managing the ensuing bloat and complexity is hard and not fun. I've done it a hundred times, little driveby features like Dark Mode that take a couple hours to implement (but no customer asked for). Then 3 months later it breaks randomly from a dependency update and it's another 2 hours to fix it. Then it adds half a day to creating a new feature that people actually did ask for. And so on. The cost of that little thing adds up and up. I'm starting to think that product design time should be handed out as a reward, rather than seen as work.
dash2 6y ago
Some arguments below blaming software bloat on nefarious action by big tech and platform owners. Maybe, but there's a simpler explanation: your computer's speed is a public good, shared by the hosted applications. When you run multiple applications, if one of them is bloated and slow, it takes up processor time and memory. This is then not available to the other applications. So your whole phone/laptop slows down. You don't blame the app. You blame the phone/laptop, and think about buying a new one. As a result, there is little incentive for app developers to create lean, speedy applications. This is a standard public goods problem. Apple may perhaps be deliberately slowing their computers down with software upgrades, but they probably don't need to. They can just wait for app developers to do it for them. This argument also challenges the article's optimism that slow apps create a market opening for faster apps. In particular, while faster startup is something users notice (and blame on the app), memory bloat is not. So developers are likely to (over-)optimise for startup speed, at the cost of being memory-hungry, which in time slows the whole computer down.
i0n1 6y ago
I don't see how this is tied only to the new M1 CPU. All systems and OSes suffer the same faith eventually. That's why you don't use your machine from early 2000s with modern apps. For me it seems that his statement shows some envy.
- i0n1 6y ago
  "If a feature is going to cost start-up time, I would rather not have it." Well, I strongly disagree... and I'm sure I'm not the only one. Imagine being at the restaurant ordering a pizza. There are only 2 pizzas in the menu: one with 1 topping, the other with 3 toppings. Each topping would take an extra minute in pizza's prep time. Which one would you pick? The one that is being delivered faster? Or the tastier one? I think for most of us the answer is obvious.
account42 6y ago
It is interesting that the example given for startup times are browsers when that is one of few applications where I don't care that much about startup times because I have the browser always running anyway.
specialist 6y ago
The SuperHuman webmail client claims to have a 100ms rule. https://www.acquired.fm/episodes/superhuman https://www.acquired.fm/episodes/superhuman It'd be nice to work for an org like that. My entire career, any performance tweaking has had to be skunkworks, has never been rewarded. At my very first tech dev job, my coworker and I speed up a novel workflow, as in brand new technology (think OCR for blueprints), about 4x faster. Made our new service practical. We were so thrilled. Boss man was unimpressed. "You should have thought of that before." I'm still angry about it. Clearly. Ok. Wait. That's not entirely correct. A recent team did claim to have targets for P90, P99. So we measured. But it wasn't systematic, nor global. None of the other web services (teams) bothered, so our effort didn't actually matter. And even then my team wasn't willing to sacrifice our sacred cows to consistently attain the P90, P99 targets.
lashkhi 6y ago
> But when I saw it boot nearly instantly instead of the five seconds it took to Firefox, I immediately switched and never looked back. Chrome didn't beat Firefox just because it was faster. It got popular because it was promoted on a Google's home page and google products that were used by million users already.
ricardobeat 6y ago
I don't get the scorn against the 'faster than 98% of PC laptops' line. The linked article doesn't further the point either. Pretty easy to guess they are comparing to 98% of laptops sold - how many units of Alienware or RTX 2060 laptops are actually sold?
- deergomoo 6y ago
  Agreed. While these laptops are certainly great, the claim is quite believable and not that impressive when you consider how truly mediocre the average laptop is.
AnIdiotOnTheNet 6y ago
Why am I not surprised that several of the top comments here immediately turn around and blame their bosses? As though the problem doesn't also exist in FOSS software! Yeah, lets just say it is all management's fault while we develop with an eye towards leaving for greener pastures in 2 years. Ooh! Is that a new shiny framework? Disgusting.
- izacus 6y ago
  "Why didn't you write this code in more efficient framework and structure it for performance?" "But that's not fun and I don't have time, need to hack the new one!"
arendtio 6y ago
About 5 years ago, I had this Windows 95 PC laying around and started it to see if it still worked. To my surprise that some old hardware felt very fast for many tasks. That was the moment, I realized that we are doing something wrong today and that performance should always be evaluated.
dusted 6y ago
I'm not sure what the author tries to say, maybe that's the entire point. The article does lay out some observations that I agree with and are interesting. I take away from it, that there are opportunities in the fact that big-bloat will continue, and that the opportunities are in building fast and light software that performs exceptionally on what is considered low-range hardware of today, and incredibly on high-end hardware. What is your takeaway?
deleted 6y ago
[deleted]
grifball 6y ago
I think hardware architects might hate hearing this but their work enables lower skill engineers to enable more functionality in less time. This wasn't quite mentioned in the article. Having faster hardware means you can run automated more security checks and more functional checks, in the same functions that run on less powerful hardware. The performance of your program can also survive some useless checks you've thrown in or some slow algorithm like a bubble sort. This slows down the end program but means that it was much easier to program in the first place. We want to imagine that the extra processing power we're building hardware for will be used to do awesome things like machine learning or PQC. But in reality it just lets some lazy idiot like me finish their project faster, which isn't a bad thing! Computer technology is expanding like crazy and it's almost impossible to keep up with it. Easing the transition from idea to code is worth wasting a bunch of cycles imo.

321 points by pmarin 6y ago

php sites get replaced by nodejs sites that use 3x the resources and eventually crash or cause problems in the client's browser due to a socket issue.

routerl 6y ago

"Software is getting slower more rapidly than hardware is becoming faster" https://en.wikipedia.org/wiki/Wirth%27s_law https://en.wikipedia.org/wiki/Wirth%27s_law

TwoBit 6y ago
I don't think this is mostly true. Many classes of applications are running perceptively similar to before but accomplishing much more. Easiest example is game software. But it’s true enough for web browser software if you can extract the crippling effect of today's ad networks (which many people do via a plugin).
- ryandrake 6y ago
  Are they really accomplishing that much more? Or are they being used to create and destroy containers of ClassFactoryProxyBuilders over and over? The topic reminds me of “24 Core CPU and I Can’t Move My Mouse” [1]. We deploy faster and faster hardware and use it for what? For holding global locks, iterating through object tables and navigating through abstraction after abstraction until the call stack is 100 calls deep. My word processor today is about as UI responsive as MS Word was in the 90’s and I use pretty much the same features now as I did before. Visual Studio Code’s UI is noticeably slower on my modern CPU than Visual C++ 6 was 30 years ago, although to be fair it compiles much faster today. 1: https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/ https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and...
  - outsomnia 6y ago
    > abstraction after abstraction until the call stack is 100 calls deep. If the software is maintainable and has less bugs, this is not a crazy way to spend the cycles. Web browsers run insanely stable over very long periods of time when you consider what's under to hood.
    - lmm 6y ago
      Yep. Remember how often Word would crash in the '90s? We were warned to save our work regularly lest it be lost. Make it work, then make it right, then make it fast. We shouldn't even begin to worry about performance until we've got a handle on correctness, and frankly software in general isn't there yet.
      - TeMPOraL 6y ago
        That's nice in the abstract, but in real life, shitty performance costs people money and sanity right now, and that cost scales up with the number of users. Also, arguably, auto-saving existed in 90s - and the primary reasons it wasn't as nice as it was today were UX (wasn't enabled by default IIRC) and hardware (spinning rust wasn't good enough to support transparent auto-saving every other second).
        lmm 6y ago
        > That's nice in the abstract, but in real life, shitty performance costs people money and sanity right now, and that cost scales up with the number of users. So do crashes, and so especially does silently outputting the wrong answer. Slow but reliable beats fast but flaky every time, and it's much easier to speed up a working program than fix a flaky one.
    - TeMPOraL 6y ago
      > If the software is maintainable and has less bugs, this is not a crazy way to spend the cycles. It's not? Consider: to make your workflow easier, you impose costs - real costs, in both emotions and money - on every single one of your users. And the more users you gain, the more the society ultimately pays for a fixed benefit of making it easier for your team to do the work. To some degree, this trade-off is necessary, but I propose that it's absolutely crazy to consider taking it unless it is necessary.
- Tepix 6y ago
  > ... but accomplishing much more. Easiest example is game software. Ha! Are you saying the old games that ran faster didn't bring us joy?
  - maccard 6y ago
    I think that's a really disingenuous reply. He's clearly saying that the processing power advancements have shown significantly in games;commodity hardware now performs real time ray tracing in 3d in a photorealistic depiction of a real life city for not-much-more-dollar-cost than the N64 did when it was launched 25 years ago. Whether it brings you more joy or is more/less fun is irrelevant
    - Tepix 6y ago
      It was a tongue-in-cheek reply of course, but there's some truths to it. Just like 4K resolution doesn't make movies better, adding raytracing or fancy shadows doesn't turn a bad game into something that's more fun than, say the Super Mario Bros. (1985, 31KByte) on NES (2KB RAM) which sold 40 million copies. We need to question ourselves every now and then why we are adding things like cutting edge graphics to games (and adding complexity in general). Which is what this article is about.
- TeMPOraL 6y ago
  That's nice that you mention games, because they're a great baseline for what your hardware can do. I personally use it as a sanity check. I look at the amount of data processing the software I'm building does, compare it mentally against the amount of data processing a random videogame from 10 years ago did, and ask myself (and the team), how come our software does much less work than that game, and runs much slower than that game did a decade ago? (And the answer very often boils down to: lots of unnecessary parsing or string processing, and bad choices in data structures. Both relatively easily fixable, if one bothers to look for it - and both mistakes that could have been avoided in the first place at little to no cost in developer effort.)
lpa22 6y ago
With as recent of a phenomenon as bloated software feels, I was shocked to see the 1995 date on this quote
- ainar-g 6y ago
  Niklaus Wirth is a visionary, and his legacy is honestly severely underappreciated. Pascal was a reasonably well designed language for its time and purpose. The Oberon ecosystem has in many ways inspired Plan 9 From Bell Labs and, transitively, the whole post-Unix movement. His book “Compiler Construction” is still one of the most accessible introductions into the world of compilers, which I recommend to anyone interested in the topic.
taneq 6y ago
Try using a 20-year-old machine, even a freshly installed machine running contemporaneous software is painfully slow compared to a modern econobox.
- brazzy 6y ago
  I have a desktop PC that I built from cheap components 10 years ago (first generation core i3). It doesn't feel particularly slow at all using most current software.
  - sumtechguy 6y ago
    You may just be used to it? I just did an upgrade this year to something way more current. Using my old computer feels 'sluggish'. Last year this time I would have said the same as you about that same computer. The new computer is from cold power off to useable desktop in under 5-10 seconds. The old one was more like 60. If the computer is serving your needs then there is no issue really. For me it was some new bits of software just did not cut it on the old one.
    - brazzy 6y ago
      No, I have my pretty new work laptop as a comparison. Maybe I'm just not using any really resource-hungry new software.
- pjmlp 6y ago
  No need for contemporaneous software, for many people a 20-year-old office of some kind is more than enough, plus email. :)
- AnIdiotOnTheNet 6y ago
  I have an old XP laptop in my office, which I keep around because it still has a serial port. Every couple of months I have to use it and I'm always a bit unsettled at first by how responsive everything is because modern software has made me so use to everything feeling like molasses.

etaioinshrdlu 6y ago

Maybe Apple could use their walled garden to tax developers based on the amount of resources their app uses. You need $100 to put your App in the store; you need to pay $1000 to use more than 10% of CPU performance; you need to pay $10000 to have an app bundle more than 10MB; and so on -- charging ridiculous amounts for access to high-performance battery-draining features. For dealing with app developers with deep pockets like Google -- you could charge the developer something egregious like $10 per install. At some point the screws are tight enough that you just build your app to behave better. It would be absolutely dastardly -- but could actually have the effect of forcing app developers to care about performance :) They won't care unless they have to. Web developers have to care about performance because of SEO (and click metrics...) but it only goes so far because it's not forced. I disagree completely with the walled garden model of iOS (and the direction of macOS) but, if it nonetheless exists, I'd like to see them do something hardcore like this. The performance and battery gains would be out of this world.

gear54rus 6y ago
Yeah because you will be the one deciding what's normal for a given piece of software... If someone implements that bs policy it surely would be apple.
annilt 6y ago
Search engines should punish slow/big/bloated websites or promote light ones. Is google doing something for that? It is so annoying to spend time on web nowadays. I find myself skipping search results when website looks bloated to me. So it is like ‘search something, quickly look at results, try to click on most accurate and lightweight looking link, if website is actually bloated click back without waiting it to be fully loaded and try again on another link.’
- etaioinshrdlu 6y ago
  Google definitely uses pagespeed as a major factor. They may also with AMP although that may be changing. They could do more though.
6y ago

vosper 6y ago

> It is normal that doing more takes more resources. Modern raytracers require more processing power because they generate better images. Likewise, compilers of 2020 have awesome static code analyzer which they did not have in 2009. > But doing the same thing should never become slower. Starting up an application should never take longer than it used to. If a feature is going to cost start-up time, I would rather not have it. No feature, no matter how great, could ever justify a slowdown to start-up time? That seems like an absurd position to take. Also, if you read the link to the “law” about software taking up more compute resources over time, you’ll find that the origin is Intel’s Andy Grove complaining that Microsoft wasn’t taking advantage of newer, more powerful chips. Also the title is just kind of rude and dismissive to software engineers - it’s not true that noone at all cares about performance.

astrange 6y ago
> No feature, no matter how great, could ever justify a slowdown to start-up time? That seems like an absurd position to take. This is actually the WebKit project's policy. Performance regressions are not allowed and you can't commit any without adding an equivalent progression.
pmarin 6y ago
Just to be clear. I am the OP. the real title is "These are called opportunities". I used one of his cites [1] as title because the original was not catchy enough. The article was submitted a couple of times with 0 upvotes [2]. The big apple logo doesn't help either. [1] https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law [2] https://hn.algolia.com/?q=https%3A%2F%2Ffabiensanglard.net%2Fsilicone%2F https://hn.algolia.com/?q=https%3A%2F%2Ffabiensanglard.net%2...
- vosper 6y ago
  So... you editorialized the title in order to get some traction? I hate to be that guy, but the HN guidelines ask not to do that > please use the original title, unless it is misleading or linkbait; don't editorialize I should have checked the real article title, it’s much more reasonable. I see that it has been changed here, now.

razorunreal 6y ago

If companies like Apple didn't try to make things as incompatible as possible, maybe software engineers wouldn't have to keep adding new layers of abstraction and things would run a bit faster. There's basically a never ending war between platform developers trying to create lock-in and app developers trying to escape with new cross-platform technologies.

tgv 6y ago
That's unfair in this context: Apple has been using the most mainstream desktop/laptop/server CPU architecture there was (and still is using it in certain models), and their new processor is ARM, which may be the most ubiquitous architecture at the moment. They're doing nothing that requires adding new layers of abstraction for normal software engineering.
- est31 6y ago
  I agree with you on the processor part, but them using Metal instead of Vulkan while deprecating OpenGL doesn't really help game engine developers who want their code to run on Android, Apple, Windows (and maybe Linux) devices.
  - nlitened 6y ago
    If I remember correctly, Metal predates Vulkan, so the argument could be vice versa :)

remolacha 6y ago

In many circumstances, it’s better to optimize for developer time over compute time. I’m glad that I can choose from zillions of (slower than necessary) web/electron apps instead of a smaller number of “optimized” apps written by “real engineers”.

tgv 6y ago
As hinted at in the article, that becomes technical debt that can be really difficult to get rid of later. Of course, optimizing may create another kind of debt, but that Firefox has lost the race from a very convenient lead is telling. Ideally (IMO), if you want to optimize development time, also consider future development time.
- arvinsim 6y ago
  Technical debt means guaranteed work in the future for software developers. I only say this half-jokingly.
  - astrange 6y ago
    The problem is that it gets exponentially harder to fix something the later you do it. Even if you wait a few years it could be easier to rewrite from scratch than fix a large bug. Btw, people bring up a features vs. speed tradeoff here and I don't think it's true - in my experience perf issues come from stupid random bugs more often than they're fundamental parts of new features. There is definitely a development time vs speed tradeoff, though; the best way to save time here is to have really good regression tests.
tonyedgecombe 6y ago
I don't know if we have optimised developer time either. I'm certainly slower when doing anything on the web than I was with VB6.
- jbverschoor 6y ago
  People like to think they're smart. Being able to use complex things makes you look smart. Creating a complex system makes you look even smarter.

tasty_freeze 6y ago

The author says that he switched to Chrome and never looked back because when it came out, it booted up in under a second. > Firefox developers famously attempted to fix the five second startup time in 2010 via bug #627591[6]. They fixed many issues but not enough to warrant a second try. It would be a great point if Chrome still started up in under one second. In one data point, there isn't much difference. Plus I typically (re)launch the browser less than once per day. The time difference on start up isn't the deciding issue for me.

TwoBit 6y ago
I've never understood the launch value. You start an app once a day - or in my case once a week - and run it for hours thereafter. He should have talked about Chrome's speed, which was significantly faster ten years ago, though not enough now for me to care.
- vosper 6y ago
  You’re right - one of the great unheralded achievements of modern computing is that most people can run all the applications they need (of which there are more, all of them more powerful than ever before), all at the same time, on a middle of the road laptop, and never have to think about it. You launch them once, when your computer starts, and that’s it. Office, Excel, Figma, 5 other web-apps, Slack, 30+ websites, Spotify - no problem.
- annilt 6y ago
  He uses Chrome as an example. You can think of a website instead of it, its ‘start up’ time always matters and almost all websites are slower than 10 years ago
- meheleventyone 6y ago
  Depends on the usecase but we find Chrome to be significantly faster than Firefox in JS performance.
bryanrasmussen 6y ago
>The author says that he switched to Chrome and never looked back because when it came out, it booted up in under a second. perhaps this can be taken as a claim to being a typical consumer, as they are often described as not especially rational. (the never looking back part)

PradeetPatel 6y ago

With the modern cloud computing paradigm, it's a lot easier to produce code and let it scale horizontally than to write optimised code, thus speeding up the delivery cycle.

ensiferum 6y ago

People want more behavior and more data. more data needs Better algorithms for processing and it's very easy to fall off the performance cliff with a bad algo that doesn't scale well. Add multiple layers and it's not always obvious what the total complexity is.

saagarjha 6y ago

I’m not sure if this qualifies as an “unpopular opinion”, but I get a predictable amount of flak whenever I bring it up: I think the assumption that a company should outfit their developers with “the best” machines is problematic. If my company could give me a brand new 13” MacBook Pro from a couple years ago, I’d take it over the 16” 2020 model I have. To many the hardware a company gets its engineers is some sort of inviolable measure of how much they love you, and a company that doesn’t buy you the beefy model of the latest laptop is clearly a horrible place to work. But personally I tend to use moderately old hardware and then upgrade every once in a while to the latest model, and every time I’m always interested to see how some software can go from being utterly unusable to “reasonable”. I read articles about how Discord made their app’s scrolling 60 FPS and I go “yeah, right” because my iPhone SE gets nowhere near that…but on my iPhone 12 mini it kind of actually does. Trying to run any sort of Swift Playgrounds or previewing on my Early 2015 MacBook Pro is an exercise in frustration…but throw two extra cores at it and give the process a couple more gigabytes of RAM and it’s usable. It’s clear that all of these things never get tested beyond the high-powered machine that the developer used. And I don’t see the trend of developers being completely out of touch of what devices their users are using going away anytime soon. But maybe we should start considering “experience correction” tools as part of a regular testing methodology. A friend of mine once lamented that the web would be a much better place if opening the Chrome developer tools automatically enabled the network throttler, and I think I’d have to agree with him.

arcticbull 6y ago
Your job is to make money for the company. Your job isn't to build the smoothest, most optimized, experience for your customers. It's to build features customers want or need, which in turn create value for your employer. This generated value pays your paycheck. Of course if you do a bad enough job, it's counterproductive, but to the extent it's not bad enough your job is to focus on features and development and not on optimization. Once performance is bad enough, your job becomes optimization -- via instrumentation, measurement and profiling. Every minute you spend waiting on a build or waiting for an app to launch or waiting for some long-running task to finish is a minute you're not creating value. Compounding this problem, it impacts morale if you spend your day looking at spinning beach balls while your boss won't get off your back about when you'll be done. This is your employer's perspective, more than likely. [edit] Another way of looking at this is to say that you and your customers are doing different jobs. You have all the extra cpu and memory overhead of developing a product — all they have to do is run it. By definition your workload is more demanding.

pfranz 6y ago

Browsers seem to be one of the few apps where they compete on speed. I remember Firefox was peeled out from the Mozilla browser and liking it because it was much faster and lighter. Similar to the quote about Chrome in the article, speed came up quite a bit when Safari was developed almost a decade before Chrome. > The number one goal for developing Safari was to create the fastest web browser on Mac OS X. When we were evaluating technologies over a year ago, KHTML and KJS stood out. [1] > Don Melton: That's just perfect for me. In another life, I was a QA engineer. I run the tests, and if I detected we were slower, I closed the tree. That was the beginning of my policy, that policy that I pulled out of my hiney. Boy, talk about making yourself popular on your team doing that! [2] (on his no regressions policy) [1] https://marc.info/?l=kfm-devel&m=104197092318639&w=2 https://marc.info/?l=kfm-devel&m=104197092318639&w=2 [2] https://www.imore.com/debug-111-don-melton-blink-servo-and-more https://www.imore.com/debug-111-don-melton-blink-servo-and-m...

jasonhansel 6y ago

This seems like a case of the Jevons Paradox, where the "resource" is CPU cycles: https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox

epicureanideal 6y ago
I wonder if this can be applied to the labor market? As technology makes workers more efficient, demand actually increases? Or for example, software engineers. As software becomes cheaper to produce, demand for it increases?
- sleepy_keita 6y ago
  Parkinson's law https://en.wikipedia.org/wiki/Parkinson%27s_law https://en.wikipedia.org/wiki/Parkinson%27s_law

brundolf 6y ago

> But doing the same thing should never become slower But none of the described software is doing the same thing it was before. This author is saying "well, you know, it's still a photo editor, same thing" and "well, you know, it's still a web browser, same thing". But those are gross oversimplifications of how a major piece of software evolves over the course of a decade.

saagarjha 6y ago
Perhaps, but when people are using the software in the limited capacity it would still be nice to have the "old" performance. I think people would be far more forgiving of Slack's performance problems, for example, if sending a simple text message didn't require as much RAM as a video call, or their IDE's performance if typing was as smooth as it is in vim but the complicated analysis stuff took a little longer to come in.
annilt 6y ago
Problem is these softwares can be made as fast as they were before but instead of investing time on performance/resource usage, developers see more value on extra features. So you end up with a fully featured but slower than ideal software. Even it is slower, still in acceptable limits to the majority of users.
- arvinsim 6y ago
  > developers see more value on extra features. Yet another post blaming developers when it's the product managers and business development people that decide the direction of the product.
  - annilt 6y ago
    I’m not blaming developers. Indeed extra features are more valuable(for users/marketing etc.) than performance most of the time. So, it’s completely normal. More hardware will lead to more features and bloat. There is no one to blame on that.
  - izacus 6y ago

mullingitover 6y ago

It's a pretty straightforward law of physics: software is a gas that expands to fill its container.

__MatrixMan__ 6y ago

I'm under the impression that you can run pretty much anything in web assembly, which is like a whole tiramisu of abstraction above the hardware. Not sure how many more cycles that ads but I bet it's quite a few. Is it possible that we're inventing all this encapsulation because we think we can escape an ugly truth at a higher layer? Is it possible that we're wrong about that?

timdaub 6y ago
Yes and no. WebAssembly itself has no IO except for its linear memory. So many programs will then have to have a component in a system-native language (e.g. to write files). So technically I'm not sure how much you can abstract away for performance.
3pt14159 6y ago
It's about security and ease. If it were secure to install arbitrary code on a computer, we'd have more apps. If it were easy to compile across platforms and handle every weird OS call, we'd have way, way more apps. Browsers are essentially a translation layer with some security guarantees and even there, on both counts they aren't perfect. They're merely better than the alternative. If you ever want to disrupt the entire industry, make something that is easier to code for and more secure than a web browser. If it's faster too, then that's gravy.

txdv 6y ago

Part of the problem is that software engineering time is more expensive than just buying better hardware or letting the end user deal with the slow software. So business just buy better available hardware rather than spending time optimizing and end user want usually the cheapest product. There are only a few organizations like Sublime HQ who focus on fast software. But they are producing niche products, catering to other software developers who appreciate the fast nature of their software and have the money to spend on it. I personally bought Sublime Merge and my IT friends who make a lot of money are perplexed by my decision spending 100 on an amazing development tool. I also sometimes dream with my programming buddy about creating a company which creates fast software like Sublime HQ, but it is really hard to sell this kind of software.

est31 6y ago
It depends on the number of users. If say Slack got 10% faster, it'd deliver tremendous productivity increases for customers all around the world. So in theory, there is a large incentive here, and Slack can absolutely capture a part of the value they'd be creating from doing such a speedup. But Slack is a product with many users. Speeding up highly specialized products that have maybe 100 users doesn't create as much value.
- txdv 6y ago
  If you reach Facebook scale and optimize a flow by 10%, you can basically save thousands of dollars per month making optimizations valuable for the company again. This is one of the aspects where optimizations starts making sense again.
  - tonyedgecombe 6y ago
    The trouble with Facebook is the obvious optimisation for them is to offload work from their servers to my device. Hence we get bloated clients.
    - txdv 6y ago

boberoni 6y ago

> If a feature is going to cost start-up time, I would rather not have it. Is it that we don't care about start-up time? Or is it that we don't have the choice? We still care about start-up time, but there's diminishing returns to this sort of optimization. Moreover, the developer teams have to balance these factors with a variety of other product features and with optimizations for developer productivity. Gains in hardware performance might be wasted by slow software, but "fast software" can certainly reap the benefits. By "fast software", I mean computation heavy workloads like ML training, image processing, etc. The article touches on this. > But doing the same thing should never become slower. Starting up an application should never take longer than it used to. I would not consider starting up Xcode in 2008 and starting up Xcode in 2020 to be "doing the same thing". Through many years of updates, this application has become very different. I personally don't use Xcode, but I would hope that Xcode 2020 has more features than Xcode 2008. Now, whether Xcode 2020 actually NEEDS all those new features is a different questions, especially if it comes at a cost to start-up time. As individual users, it may feel like we have no choice in these decisions. However, the optimist in me wants to think that we DO have a choice. We can still "vote with our behavior". If Xcode is too slow, users will stop using it and prefer alternatives that provide the performance that we want. However, if users continue to use Xcode in spite of slow start-up time, then perhaps there's something more important that's keeping users around.

flohofwoe 6y ago
> but I would hope that Xcode 2020 has more features than Xcode 2008. No, not really, and definitely none that need to be initialized at application startup. There are some truly baffling performance regressions in Xcode over the last years. Like starting for the first time into the debugger taking almost half a minute. > If Xcode is too slow, users will stop using it and prefer alternatives that provide the performance that we want. There are no alternatives if you want to build iOS applications. You'll at least need to use the Xcode command line tools for this, and some of the performance problems (like the slow start into the debugger) seem to be rooted there, because VSCode has the same problem.

tjansen 6y ago

There is an easy explanation for this: developers optimize their code when the product owner tells them to spend time on this. The product owner will tell them to optimize when product owner notices that the software is getting too slow. When new hardware is released, slowdowns that would be visible on older hardware won't be easily noticeable, so programmers will work on other features rather than optimizing code. Until the code becomes too slow to run on current hardware, then they work until it becomes usable again.

tsjq 6y ago
Totally this
AmericanChopper 6y ago
The thing hardware engineers are missing here is that people don’t want to use their improvements to improve speed. They want to use them to pay for more expensive abstractions that allow them to develop software faster. Unless you have a performance issue that’s really pathological, speed really doesn’t matter for most applications. I’ve developed dozens of python web applications. Python is slow as hell, but I can count on one hand the number of times hand where I found the RoI of optimizing a performance issue to be more valuable than feature development (and all of them were problems that couldn’t be solved with more hardware, which is the default best-RoI way to approach most performance issues).
- nitrogen 6y ago
  I think distinguishing between client-side and server-side speed matters. Python and Ruby are fast enough, and as you say you can scale them horizontally for a long time before it gets cheaper to optimize or rewrite in another language. But if a UI is slow, that does matter. Delayed keypresses, unacknowledged but registered interactions, or the worst, delayed layout changes, are completely flow breaking.
  - AmericanChopper 6y ago
    I think my rationale applies to client side code too, just in a slightly different way. It is so easy to write performant browser UIs these days, and a lot of that is down to these same sorts of hardware improvements (as well as V8 improvements). Even bloated web app front ends will perform very well most of the time. You can take that to the extreme of course, but you really have to go out of your way to do it. I’ve built frontends before without giving any consideration at all to performance, and they’ve always performed perfectly well. Websites like cnn.com exist, so it is demonstrably possibly to do it badly, but you have to stray so far from the light accomplish something like that.

cosmotic 6y ago

New shiny libraries, frameworks, and platforms draw in developers. Those new things are typically not well polished or optimized. By the time they get optimized, developers move on to newer and shinier things. Java, PHP, .NET, and Javascript were all slow until they got fast (although with Javascript, things got really complicated and slow again). I say this as a developer that uses all those now-fast things and avoids the shiny and new for these reasons (and more, including lack of tooling).

Cthulhu_ 6y ago
But you'd think those new things would be built on top of the older, faster, 'core' libraries, and the abstraction only improves developer ergonomics while the result is just as fast if not faster. I mean compilers should empower that, allowing for good, readable code that compiles to blazing fast code. That's the theory anyway, but I know in practice it's different. I keep thinking of my time working on iOS software, where I experienced the transition from objective-C to ARC to Swift; it still felt like the end result was the same, if not even better (Swift whole-module optimization), but the developer ergonomics were much improved. Still kinda miss xcode, a shame it's not really usable for anything that isn't obj-C/Swift.

bjarneh 6y ago

> Chrome also had these. But when I saw it boot nearly instantly instead of the five seconds it took to Firefox, I immediately switched and never looked back. It really was incredible how fast Chrome seemed when it first came out; and not just in terms of startup speed; rendering speed was superb compared to the competition. Now Firefox seems much closer to Chrome in terms of rendering speed, and for certain web-pages (some company web-pages with huge tables at least) Firefox renders them noticeably faster.

jlokier 6y ago
For WebAssembly, Firefox starts some things a lot faster. I was using the WASM version of Microsoft Z3 recently (a kind of theorem prover), and it took about 15 seconds to start in Chrome, and about 2 to start in Firefox on the same machine. It ran a bit faster in Chrome after that, but not noticeably. Startup time was a bottleneck. Imagine visiting a web app then waiting 15 seconds while it's frozen before the functionality starts working.
- bjarneh 6y ago
  > Microsoft Z3 recently (a kind of theorem prover) Also a theorem prover with kinds (or more one type of elements), if I'm not mistaken :-) Firefox is getting really good; perhaps a bit memory hungry, but that's hardly where Chrome shines either...
  - jlokier 6y ago
    They call them sorts not kinds :-) "Sort" comes from many-sorted logic where the sort distinction is at the syntactic level, so easily inferred. They are not called "types" because they don't come from type theory; there is no logical richness to the relationships between different sorts, unlike the relationships between types. They are not called "kinds" because that is the name of a higher-order concept in type theory.

eb0la 6y ago

I remember spending two days hunting a bug in my Turbo Pascal code when I upgraded from a 286 machine (12Mhz) to my a Pentium-66. It was a while loop with one extra zero at the end. The loop with the bug run in twos second in the 286. Easy to notice. In the Pentium it didn't run in the blink of an eye. This way of benchmarking performance, with human wall clock time, makes performance problems add up: They add up faster, the faster your development machine is. I guess a good benchmarck would be number of cycles run; but if the software runs fast enough it's hard to justify working more time on it unless there a business need to do it faster (like you're billed by milisecond, by intruction run like in a blockchain, or it is part of the core layer of your product and performance matters to capture market share).

system2 6y ago

98% better than any laptop out there or the ones released in 2020? My windows laptop is already better than 90% of the laptops out there.

throwitaway1235 6y ago

Uninitiated, outsider, novice etc question in relation to the topic - is there a reason banking websites are a bloated nightmare to navigate, regardless of my devices capabilities? Chase is the worst. So slow I've missed credit card payments over it.

high_priest 6y ago
I've been in contract with the leading bank in my country ever since they introduced their "online focused" branch and never had any issues nor have I directly paid for any of the provided services. Now, every time I saw someone work through software of some other bank, it was an atrocious experience. So, look into the offer of the largest bank in your country. It's most often the main bank in your country. If they promise to not bill you for the services you need, there is nothing to lose from switching to them.
- throwitaway1235 6y ago
  Thank you.

4778468d 6y ago

I’d love a new Mac mini but 16GB of RAM just doesn’t cut it any more. If it was 32GB I’d buy. But a fast CPU is only marginally useful when my machine grinds from memory swapping.

0898 6y ago

Is there a Wordpress theme that will make my website look like OP's?

pragnesh 6y ago

I think firefox is again faster and leaner compare to chrome.

baxtr 6y ago

> We carefully monitor startup performance using an automated test that runs for almost every change to the code. This test was created very early in the project, when Google Chrome did almost nothing, and we have always followed a very simple rule: This test can never get any slower. That's actually very similar to how Safari was built. After Steve showed the Safari icon, he clicked to the next slide. It had a single word: Why? Steve felt the need to say why Apple had made its own browser, and his explanation led with speed. Some may have thought that touting Safari performance was just marketing, a retrospective cherry-picking of one browser attribute that just happened to turn out well. I knew better. I had been part of the team that had received the speed mandate months earlier, and I had participated in the actions he now described which ensured the speed of our browser." [1] [1] Kocienda, Ken. Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

ksec 6y ago
And Safari Story from Don Melton https://donmelton.com/2013/01/10/safari-is-released-to-the-world/ https://donmelton.com/2013/01/10/safari-is-released-to-the-w...
westwing 6y ago
Safari may be fast, especially on mobile, but it sure is holding back everyone on features. The irony is that with WebGL2 and WASM, near-native-speed applications would be possible. Also, if there were Safari APIs for all their fancy chip features, developers might actually use them widely. The problem is that if this happened, Apple would lose its monopoly on a good app experience. They need web technology to be crappy, and poor performance is part of that picture.
- nlitened 6y ago
  You're not talking about developers in general, you're talking about web developers—and holding them back a little is almost a positive thing to do at this point.
  - westwing 6y ago

jpgvm 6y ago

Personally I couldn't give a shit about startup time. I start most of my apps when I boot my machine and I rarely if ever close any of them or turn my machine off. I care about how fast said applications do their job, that they remain responsive and don't suffer from instability. Maybe I am just old/desktop user. My machine is a 9900K + 32GB RAM which is definitely fast but it's not absurd. With this amount of RAM I never feel the need to close anything other than to tidy up my list of open tabs so I can see the icons without scrolling again.

ShroudedNight 6y ago
> My machine is a 9900K + 32GB RAM which is definitely fast but it's not absurd. The 9900k appears to have similar compute throughput to a Top 500 supercomputer from 2004, a time when my Northwood P4 with 512MB RAM, and Radeon 8500 were quite comfortable running Firefox at 1600x1200 @ 85hz. A 9900K + 32G quite frankly represents an embarrassment of computing riches and the marginal improvements in end-user experience since then (mostly in the form of additional screen real estate) betray just how little we've done with that compute that truly benefits the user.

_0o6v 6y ago

> Is it that we don't care about start-up time? Not particularly. If it takes 13s to load Photoshop once a day, then I can access all these great features, that's alright with me.

pbadenski 6y ago

The test that never can get slower - I'm curious how they do it.. In my experience tracking performance regressions is much bigger challenge than solving performance issues.

zuhayeer 6y ago

“For every cycle a hardware engineer saves, a software engineer will add two instructions” To save dev time, people are no longer building native. And that bloat keeps adding up, masquerading as abstraction

ChrisMarshallNY 6y ago

I write native code, in Swift; using the built-in APIs. I also will require iOS 13 or greater in new apps (probably 14, for the ones I think may take many months before release). I try to use fairly modern techniques and patterns in my development (but I am not yet satisfied that SwiftUI is up to the task for my more complex work). It is my hope that this means that my apps will be as performant as possible. I may get an M1 Mini, as a test device, sooner or later. There’s no hurry. I am still planning on waiting for the M2 processors before upgrading most of my systems. By then, I think that most apps will have sorted themselves out.

barrenko 6y ago

To borrow a reference from Alex Crompton, building software is both "Math hard" and "Bodybuilding" hard. Coding itself is then recursively "Math" hard and "Bodybuilding" hard. Math hard is when to get something to work it's really hard "mentally" to achieve/produce/figure out, but when it works it's not a problem anymore and you can explain it to kids (like Pythagorean theorem). Bodybuilding hard is when there is clear and simple "process" to achieve a thing, but it's really hard to stick to it, because to not do so is way easier. In coding e.g, it's boring to refactor and optimize code and not put all stuff in one place and write shitty functions. In actual software development/management (one level "above") it seems it's really really hard for the team/company/PM/CEO to fight bloat. It's hard not to go for building new stuff and adding features. There is nothing to talk about and waste meetings on and add administrative and marketing staff early on if you're not working to "add new features". Mainly because there is no definable primary feature, no actual purpose for the software, no really good coders, and in 99% of cases no actual product and / or underlying business.

ritchiea 6y ago
Beyond it being "hard" to fight bloat, it's against the individual interests of most of the company. Let's say you have a job at Google or company X or wherever, you're a PM/dev/designer/manager/productGuy. You don't get promotions and earn more responsibility for saying "we don't need that feature." You get promotions for that cool new thing you shipped and hey if it ruins the UX or slows the app down or whatever, who cares if it's UX or your career what do you care about UX your career is dependent on MORE bloat. Incentives are totally misaligned but I can't imagine the situation will change anytime soon.
- marcus_holmes 6y ago
  This. Also, feature design is "playtime" for most founders/devs/designers/productGuys/managers. Thinking up cool new stuff that your product can do is fun. And, once thought up, it's hard to put that feature aside. "Wouldn't it be cool if it did this..." is easy and fun. Managing the ensuing bloat and complexity is hard and not fun. I've done it a hundred times, little driveby features like Dark Mode that take a couple hours to implement (but no customer asked for). Then 3 months later it breaks randomly from a dependency update and it's another 2 hours to fix it. Then it adds half a day to creating a new feature that people actually did ask for. And so on. The cost of that little thing adds up and up. I'm starting to think that product design time should be handed out as a reward, rather than seen as work.

dash2 6y ago

Some arguments below blaming software bloat on nefarious action by big tech and platform owners. Maybe, but there's a simpler explanation: your computer's speed is a public good, shared by the hosted applications. When you run multiple applications, if one of them is bloated and slow, it takes up processor time and memory. This is then not available to the other applications. So your whole phone/laptop slows down. You don't blame the app. You blame the phone/laptop, and think about buying a new one. As a result, there is little incentive for app developers to create lean, speedy applications. This is a standard public goods problem. Apple may perhaps be deliberately slowing their computers down with software upgrades, but they probably don't need to. They can just wait for app developers to do it for them. This argument also challenges the article's optimism that slow apps create a market opening for faster apps. In particular, while faster startup is something users notice (and blame on the app), memory bloat is not. So developers are likely to (over-)optimise for startup speed, at the cost of being memory-hungry, which in time slows the whole computer down.

i0n1 6y ago

I don't see how this is tied only to the new M1 CPU. All systems and OSes suffer the same faith eventually. That's why you don't use your machine from early 2000s with modern apps. For me it seems that his statement shows some envy.

i0n1 6y ago
"If a feature is going to cost start-up time, I would rather not have it." Well, I strongly disagree... and I'm sure I'm not the only one. Imagine being at the restaurant ordering a pizza. There are only 2 pizzas in the menu: one with 1 topping, the other with 3 toppings. Each topping would take an extra minute in pizza's prep time. Which one would you pick? The one that is being delivered faster? Or the tastier one? I think for most of us the answer is obvious.

account42 6y ago

It is interesting that the example given for startup times are browsers when that is one of few applications where I don't care that much about startup times because I have the browser always running anyway.

specialist 6y ago

The SuperHuman webmail client claims to have a 100ms rule. https://www.acquired.fm/episodes/superhuman https://www.acquired.fm/episodes/superhuman It'd be nice to work for an org like that. My entire career, any performance tweaking has had to be skunkworks, has never been rewarded. At my very first tech dev job, my coworker and I speed up a novel workflow, as in brand new technology (think OCR for blueprints), about 4x faster. Made our new service practical. We were so thrilled. Boss man was unimpressed. "You should have thought of that before." I'm still angry about it. Clearly. Ok. Wait. That's not entirely correct. A recent team did claim to have targets for P90, P99. So we measured. But it wasn't systematic, nor global. None of the other web services (teams) bothered, so our effort didn't actually matter. And even then my team wasn't willing to sacrifice our sacred cows to consistently attain the P90, P99 targets.

lashkhi 6y ago

> But when I saw it boot nearly instantly instead of the five seconds it took to Firefox, I immediately switched and never looked back. Chrome didn't beat Firefox just because it was faster. It got popular because it was promoted on a Google's home page and google products that were used by million users already.

ricardobeat 6y ago

I don't get the scorn against the 'faster than 98% of PC laptops' line. The linked article doesn't further the point either. Pretty easy to guess they are comparing to 98% of laptops sold - how many units of Alienware or RTX 2060 laptops are actually sold?

deergomoo 6y ago
Agreed. While these laptops are certainly great, the claim is quite believable and not that impressive when you consider how truly mediocre the average laptop is.

AnIdiotOnTheNet 6y ago

Why am I not surprised that several of the top comments here immediately turn around and blame their bosses? As though the problem doesn't also exist in FOSS software! Yeah, lets just say it is all management's fault while we develop with an eye towards leaving for greener pastures in 2 years. Ooh! Is that a new shiny framework? Disgusting.

izacus 6y ago
"Why didn't you write this code in more efficient framework and structure it for performance?" "But that's not fun and I don't have time, need to hack the new one!"

arendtio 6y ago

About 5 years ago, I had this Windows 95 PC laying around and started it to see if it still worked. To my surprise that some old hardware felt very fast for many tasks. That was the moment, I realized that we are doing something wrong today and that performance should always be evaluated.

dusted 6y ago

I'm not sure what the author tries to say, maybe that's the entire point. The article does lay out some observations that I agree with and are interesting. I take away from it, that there are opportunities in the fact that big-bloat will continue, and that the opportunities are in building fast and light software that performs exceptionally on what is considered low-range hardware of today, and incredibly on high-end hardware. What is your takeaway?

deleted 6y ago

[deleted]

grifball 6y ago

I think hardware architects might hate hearing this but their work enables lower skill engineers to enable more functionality in less time. This wasn't quite mentioned in the article. Having faster hardware means you can run automated more security checks and more functional checks, in the same functions that run on less powerful hardware. The performance of your program can also survive some useless checks you've thrown in or some slow algorithm like a bubble sort. This slows down the end program but means that it was much easier to program in the first place. We want to imagine that the extra processing power we're building hardware for will be used to do awesome things like machine learning or PQC. But in reality it just lets some lazy idiot like me finish their project faster, which isn't a bad thing! Computer technology is expanding like crazy and it's almost impossible to keep up with it. Easing the transition from idea to code is worth wasting a bunch of cycles imo.