These are called opportunities(fabiensanglard.net)
fabiensanglard.net
These are called opportunities
https://fabiensanglard.net/silicone/
266 comments
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.
Incentives are totally misaligned but I can't imagine the situation will change anytime soon.
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.
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.
What could be ways to motivate product managers to remove bad features
That is a really good question!
As devs we know it's a good thing, but try explaining to the average manager why we're going to spend dev time removing features instead of adding new ones. It'll be a hard conversation ;)
As devs we know it's a good thing, but try explaining to the average manager why we're going to spend dev time removing features instead of adding new ones. It'll be a hard conversation ;)
Managers (both product and engineering) know it too; that’s just not how their incentives are designed (as mentioned above).
Though I don’t have an answer for how to align incentives correctly in a modern company. If you have one visionary who owns the product forever and happens to care about UX, you can do it. But that’s not how companies work today.
Though I don’t have an answer for how to align incentives correctly in a modern company. If you have one visionary who owns the product forever and happens to care about UX, you can do it. But that’s not how companies work today.
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.
in my previous job, as a PM, I was creating tickets all the time to work on the speed of the app, but the developers didn't not want to work on them, they were saying the users don't care.
The reality is that they didn't know how to fix the speed issues.
It is easy to debug a js function, but what about when you use angular or any other js framework ?
The reality is that they didn't know how to fix the speed issues.
It is easy to debug a js function, but what about when you use angular or any other js framework ?
So I've done this a few times and constantly play with the idea of offering it as a consultancy service.
Two things put me off, I do wonder if anyone else here has attempted to do it as a consultant?
Firstly, while I could quickly identify the cause of the slowdowns, the previous times I've done this I already had an intimate knowledge of the codebase so could confidently fix the problem. Without an intimate knowledge of the codebase, I fear I'd either muck up the fix, or that I'd have to rely on internal developers who, as you say, would deprioritize it or feel resentful at an outsider coming in and from their perspective effectively telling them their code is "bad" (even though I understand how these speed issues develop organically). Or would it be enough to just offer the diagnosis, but not the fix, and thus give ammo to the PMs/senior management to take the problem to their own developers and say "look, we've been told there's a problem and it's fixable, go fix it".
Secondly, how to handle getting access to their codebase/a proper debug environment that reflects production for such a short time. Again I fear it would turn into a "not my problem" scenario of trying to get a live environment setup from people who don't want to give it to you. Fixing these problems usually turns out to be fairly quick once you've identified the real cause. I can do a quick analysis just with access to a website (i.e. is it a back-end or front-end problem), but until you can run diagnostics you can't say exactly which loop/sql statement/js compilation issue/etc. is causing the problem.
Two things put me off, I do wonder if anyone else here has attempted to do it as a consultant?
Firstly, while I could quickly identify the cause of the slowdowns, the previous times I've done this I already had an intimate knowledge of the codebase so could confidently fix the problem. Without an intimate knowledge of the codebase, I fear I'd either muck up the fix, or that I'd have to rely on internal developers who, as you say, would deprioritize it or feel resentful at an outsider coming in and from their perspective effectively telling them their code is "bad" (even though I understand how these speed issues develop organically). Or would it be enough to just offer the diagnosis, but not the fix, and thus give ammo to the PMs/senior management to take the problem to their own developers and say "look, we've been told there's a problem and it's fixable, go fix it".
Secondly, how to handle getting access to their codebase/a proper debug environment that reflects production for such a short time. Again I fear it would turn into a "not my problem" scenario of trying to get a live environment setup from people who don't want to give it to you. Fixing these problems usually turns out to be fairly quick once you've identified the real cause. I can do a quick analysis just with access to a website (i.e. is it a back-end or front-end problem), but until you can run diagnostics you can't say exactly which loop/sql statement/js compilation issue/etc. is causing the problem.
I take contract work and I try hard to check in some speedups in every project I touch. It's not hard to find issues. Just profile, most people never do. The other trick of finding problem code is to talk to the sysadmins - they tend to know and often are not shy about criticising those awful lazy devs :)
I don't think you can offer it as a consultancy service because people tend not to care and are quite aggressive about that. They would much prefer to pay for more hardware and doing so is organisationally respectable: "the cloud will solve our problems".
I don't think you can offer it as a consultancy service because people tend not to care and are quite aggressive about that. They would much prefer to pay for more hardware and doing so is organisationally respectable: "the cloud will solve our problems".
A few of my clients asked for it and kept raving on about the improvements long after it was done. Which is one of the reasons I considered it.
I think programmers might not care, I'm not sure their managers and PMs don't.
I think programmers might not care, I'm not sure their managers and PMs don't.
My solution to this issue to to hire only former C/C++ video game developers for non-video game software development. Their attention to performance is innate, their attention to critical obscure details is innate, and their desire to write code they are proud is innate. Plus they come with advanced, useful math knowledge. I love former game developers because they did the pop culture dev job, saw it was exploitation, and took their incredibly optimized skills elsewhere.
We do this a lot. We take a truth + mix it in with our personal situation and broadcast this information as truth and someone comes around and follows this and finds it to be untrue.
Hiring ex C/C++ game developers is fine on the surface. They are smart people and can pick up things quickly.
But as a general rule it fails.
Taking longer to get things perfect is usually not a tradeoff in the webworld that makes sense. People want simple, reuseble and quickly changable features. Pixel perfect perhaps but never code perfect because things change quickly. Why would you hire for that?
Higher salaries for no reason.
Learning curve will be harder than one expects
Smaller pool.
Greater unhappiness. You might hear after writing a game engine that web work is 90% easier but so boring.
Hire an ex c/c++ developer because they show an interest in making a change and are willing to put in the work. Don't hire all of them and expect an advantage..
Hiring ex C/C++ game developers is fine on the surface. They are smart people and can pick up things quickly.
But as a general rule it fails.
Taking longer to get things perfect is usually not a tradeoff in the webworld that makes sense. People want simple, reuseble and quickly changable features. Pixel perfect perhaps but never code perfect because things change quickly. Why would you hire for that?
Higher salaries for no reason.
Learning curve will be harder than one expects
Smaller pool.
Greater unhappiness. You might hear after writing a game engine that web work is 90% easier but so boring.
Hire an ex c/c++ developer because they show an interest in making a change and are willing to put in the work. Don't hire all of them and expect an advantage..
Who says programmers are responsible for pixel perfection? That's what the graphic artist do. But I get your point of thinking former game developers would be too exacting. That is what hiring filters and management is for, so you hire with reason and guide them to the company's level of production quality.
Also, the typical game is significantly larger than any single gamer experiences, and game developers certainly know the tradeoff of "good enough". Plus game production environment is a technological feat in itself too, and it is those type of game developers that contain the most value - not necessarily the game play developers, but the game production pipeline developers.
Also, the typical game is significantly larger than any single gamer experiences, and game developers certainly know the tradeoff of "good enough". Plus game production environment is a technological feat in itself too, and it is those type of game developers that contain the most value - not necessarily the game play developers, but the game production pipeline developers.
It's good it works for you, but in terms of webapp development, wouldn't they have very little skill at databases? And focus on optimizations that are completely irrelevant for 99% of webapps?
I've seen before code where premature, pointless or unclear optimizations used, like dogmatically using stringbuilders or avoiding boxing saving all of a couple of nano-seconds, while the SQL statement is taking 3 seconds to run due to unnecessary sub-selects because the developer doesn't grok set-based logic. Or worse, cursors because they think they need a loop!
I've seen before code where premature, pointless or unclear optimizations used, like dogmatically using stringbuilders or avoiding boxing saving all of a couple of nano-seconds, while the SQL statement is taking 3 seconds to run due to unnecessary sub-selects because the developer doesn't grok set-based logic. Or worse, cursors because they think they need a loop!
Many game devs have their own fairly advanced web sites, and they professionally know about pre-optimization issues. Also game production environments have been using databases for decades, the game production environments certainly have optimized database operations, and their developers are experienced with this too because building an internationalized multi-language game is far more complex than the game itself.
I think we're from different worlds, from your profile it's seems you don't work on e-commerce and sass, which is what I'm referring to. Though admittedly I didn't open with that!
Just like I can't imagine the true depth of complexity of game/3d development having dabbled making games in unity, I'm not sure you understand just how complex a sass/enterprise site can get, it's usually issues with actually organising the code that gets you, rather than the code itself.
Your example of i18n is actually quite telling, having internationalized a couple of sites that's actually a fairly simple organizational problem in our codebases, comparatively not really complex at all, just tedious.
Just like I can't imagine the true depth of complexity of game/3d development having dabbled making games in unity, I'm not sure you understand just how complex a sass/enterprise site can get, it's usually issues with actually organising the code that gets you, rather than the code itself.
Your example of i18n is actually quite telling, having internationalized a couple of sites that's actually a fairly simple organizational problem in our codebases, comparatively not really complex at all, just tedious.
I authored a moderately large (scaled for global use) e-commerce / webapp / webAPI, as well as operated as a tech architect + MBA for a number of web startups. I have a pretty good idea of the complexity, architecture variations, and bottlenecks.
My example intended to reference more than i18n, as that only covers the interface. Consider something like an online international university where there is media, but that media varies with 8 different languages, so each and every aspect of any presentation needs to accommodate variable length text fields, left and right and vertical directions of text display, every media clip varies in length due to language, and multi-language users can switch display mode at will. I've done projects like this, over a dozen, and it's quite the challenge.
My example intended to reference more than i18n, as that only covers the interface. Consider something like an online international university where there is media, but that media varies with 8 different languages, so each and every aspect of any presentation needs to accommodate variable length text fields, left and right and vertical directions of text display, every media clip varies in length due to language, and multi-language users can switch display mode at will. I've done projects like this, over a dozen, and it's quite the challenge.
I've never heard a positive thought about anyone who describes themselves as an "architect" in the industry.
When hired by a "tech" startup with no technologists in their team, I call myself an architect to separate myself so they don't think I am going to be writing their code directly. Typically, such "startups" only last a quarter, because they have no experience working in tech, but I can guide them so they don't die in a quarter by providing them with a "how to be a technology developer blueprint" that tends to be received like the holy grail.
[deleted]
I find that quite fascinating. I love making things perform faster. It's one of the most rewarding things to do as a programmer, and "low hanging fruit" optimisations are usually quite simple, "mindless" work, to do in a quiet period between solving hard problems. The wins are easily measured. It can take a long time to do in a complex system, but it's usually pleasant and relaxing time.
Yeah same here! Nothing like watching a 200ms timer go down to 100ms just because you swapped out some data structure or cached some variable. It's a very satisfying game to me.
I'm old enough to have been a timesharing programmer (when a 32k->64k working memory increase seemed like limitless abundance).
The company I worked for offered very expensive timesharing by the hour. Clients used an "Englishy" interpreted language to do economic forecasts, and client staff often programmed their own procedures.
My boss came to me one day to request that I speed up something a client had developed themselves, because it had become too expensive for them to run, and they were ready to bolt.
I had no desire to understand what their code did, and so treated the code mostly like a blackbox, and my job as speeding things up while leaving the transformation of inputs to particular outputs intact.
I had enough experience to know what the low hanging fruit were and went after those in the code. A day's work or so, and we got a 50-90% speed-up, enough to satisfy the client. I still don't really know what the code did. But I enjoyed the effort.
The company I worked for offered very expensive timesharing by the hour. Clients used an "Englishy" interpreted language to do economic forecasts, and client staff often programmed their own procedures.
My boss came to me one day to request that I speed up something a client had developed themselves, because it had become too expensive for them to run, and they were ready to bolt.
I had no desire to understand what their code did, and so treated the code mostly like a blackbox, and my job as speeding things up while leaving the transformation of inputs to particular outputs intact.
I had enough experience to know what the low hanging fruit were and went after those in the code. A day's work or so, and we got a 50-90% speed-up, enough to satisfy the client. I still don't really know what the code did. But I enjoyed the effort.
Indeed. It is such a pleasure to work on purely technical challenge - no BAs, no meetings, no customers - just you and the code.
Same here. The two most interesting parts of programming to me are optimisation (mostly speed, sometimes memory though it's not needed as often) and debugging (especially when I can just reason out where the bug must be and it turns out to be correct).
I just had the pleasure of optimizing a video subsystem startup from 44 seconds to just under 2 seconds. I expect to get down to 200 ms by end of day. I love optimization.
I also love to optimize code, but I know many developers who wouldn't even know where to start.
I always start with timing it. The thing is many projects I end up in it feels like a death by a thousand cuts. Every sub function is very quick but overall together they take up tons of time. I worked one project where I took logins from 6 seconds to sub 100ms. No one cared or even noticed. Even though it was top 10 on every metric we had.
Provocatively asked: who was right?
This sounds more like an organizational problem. The project leader has to decide whether speed issues need fixing or not. If they don't need fixing, then it is indeed a wasted resources trying to do so. If they need fixing, then of course it is the task for the project leader to find the neccessary resources.
Speed issues are almost never unfixable. But, the cost of doing so might be prohibitive, usually companies deliver products which are just fast enough. The question is, with a given budget, how do you ship the better product for the customers needs? Do you want it to be fast with fewer features or not quite as fast, but having many more required features? To decide this, it is the job of the project lead, the architects and of course marketing, which has to sell the product.
And both as a project lead and a developer, I can say, it is really fun to make something faster and more efficient, but far too often there isn't the time/resources for it. Most of the time you have a customer waiting for new functionality or bug fixes much more urgently than for some speed improvements.
This sounds more like an organizational problem. The project leader has to decide whether speed issues need fixing or not. If they don't need fixing, then it is indeed a wasted resources trying to do so. If they need fixing, then of course it is the task for the project leader to find the neccessary resources.
Speed issues are almost never unfixable. But, the cost of doing so might be prohibitive, usually companies deliver products which are just fast enough. The question is, with a given budget, how do you ship the better product for the customers needs? Do you want it to be fast with fewer features or not quite as fast, but having many more required features? To decide this, it is the job of the project lead, the architects and of course marketing, which has to sell the product.
And both as a project lead and a developer, I can say, it is really fun to make something faster and more efficient, but far too often there isn't the time/resources for it. Most of the time you have a customer waiting for new functionality or bug fixes much more urgently than for some speed improvements.
This comes down to defining and generating "value".
Speed, features and bug fixes are all different forms of value. But value isn't an absolute. It's always in the eye of the beholder and depending on where a stakeholder is coming from, they are prioritized differently.
From a business perspective, balancing between different types of values is paramount. The end goal, after all, is to always deliver value that generates revenue exceeding expenses at an acceptable level.
This is why legacy software is a thing. The business assesses that an old tool still generates value for paying customers and revenue while spending an acceptable amount of time on maintenance. In the context of a large system with a large userbase, this may imply dedicating one or two developers full time towards keeping the lights on.
Many software projects don't get a rewrite. Why? Because over the course of years, business and technological contexts for all stakeholders - both the business and the customers - change so much that they become irrelevant. For instance, the business pivoting away towards a new lucrative market or product, or customers moving away to a competitor offering the same value but at a better price point and with up-to-date technology. Just consider many services and products you've used over the years and how many of them have been shelved or sunset without ever being rewritten.
While the necessity of a full rewrite may pop up over technical concerns such as security or performance. It's only when business and functional requirements have shifted away to a serious degree from the original scope of the project that organizations tend to consider dedicating time and resources to a successor. At that time, a rewrite isn't necessarily the only option: sourcing a product that does the same thing but better from an outside supplier could be a valid option as well. For instance, chucking away your own homegrown decade old CRM for Salesforce as your business grew from a 5 person outfit to a 120 person business servicing enterprise.
Speed, features and bug fixes are all different forms of value. But value isn't an absolute. It's always in the eye of the beholder and depending on where a stakeholder is coming from, they are prioritized differently.
From a business perspective, balancing between different types of values is paramount. The end goal, after all, is to always deliver value that generates revenue exceeding expenses at an acceptable level.
This is why legacy software is a thing. The business assesses that an old tool still generates value for paying customers and revenue while spending an acceptable amount of time on maintenance. In the context of a large system with a large userbase, this may imply dedicating one or two developers full time towards keeping the lights on.
Many software projects don't get a rewrite. Why? Because over the course of years, business and technological contexts for all stakeholders - both the business and the customers - change so much that they become irrelevant. For instance, the business pivoting away towards a new lucrative market or product, or customers moving away to a competitor offering the same value but at a better price point and with up-to-date technology. Just consider many services and products you've used over the years and how many of them have been shelved or sunset without ever being rewritten.
While the necessity of a full rewrite may pop up over technical concerns such as security or performance. It's only when business and functional requirements have shifted away to a serious degree from the original scope of the project that organizations tend to consider dedicating time and resources to a successor. At that time, a rewrite isn't necessarily the only option: sourcing a product that does the same thing but better from an outside supplier could be a valid option as well. For instance, chucking away your own homegrown decade old CRM for Salesforce as your business grew from a 5 person outfit to a 120 person business servicing enterprise.
[deleted]
>in my previous job, as a PM, I was creating tickets all the time to work on the speed of the app, but the developers didn't not want to work on them
In my experience it is always the PM or product owner telling me not to work on improving speed. How slow was the app, I guess the devs would be right if it was like 2 seconds or less to load/render, at that point working on speed has diminishing returns.
In my experience it is always the PM or product owner telling me not to work on improving speed. How slow was the app, I guess the devs would be right if it was like 2 seconds or less to load/render, at that point working on speed has diminishing returns.
It's actually easy in JS frameworks too (at least React, not sure about Angular which is just generally more difficult to work with). In fact, they make it much easier to write performant UI code (that's half the benefit).
You generally don't need to debug the framework. Just follow some simple best practices and the performance will just happen in 99% of cases.
You generally don't need to debug the framework. Just follow some simple best practices and the performance will just happen in 99% of cases.
> It is easy to debug a js function, but what about when you use angular or any other js framework ?
As someone who worked on a successful web-application perf-improvement project in a past life, my top 3 tricks were: 1. Profile, and use flame-graphs & call-graphs (with counts) to identify which parts are slow 2. Don't do unnecessary work 3. Execute code asynchronously whenever possible (requires balancing with code readability)
Not doing unnecessary work may be straight forward, and sometimes very complicated. Simple: some results are discarded, or some expensive functions are called for a minor side-effect just because developers were told to "maximize code reuse" at all costs. Complicated: understanding which function calls that unexpectedly block/delay browser rendering/painting
As someone who worked on a successful web-application perf-improvement project in a past life, my top 3 tricks were: 1. Profile, and use flame-graphs & call-graphs (with counts) to identify which parts are slow 2. Don't do unnecessary work 3. Execute code asynchronously whenever possible (requires balancing with code readability)
Not doing unnecessary work may be straight forward, and sometimes very complicated. Simple: some results are discarded, or some expensive functions are called for a minor side-effect just because developers were told to "maximize code reuse" at all costs. Complicated: understanding which function calls that unexpectedly block/delay browser rendering/painting
Or they are unfixable. And explaining why to a non technical pm can take all day.
At some point you will end up with a maximum, a "best I can do with this code", but it's often a constraint because of the underlying architecture; you can't make Angular any faster, but you can consider shifting to a different framework. You can't make webapps any more memory efficient, but you can consider building a native app. You can't make processing a TB of data on a single computer faster, but you can consider making it a distributed, horizontally scaled task.
Do you want to give a non-technical that option? As they could easily just hear the "here is how to fix it", ask for it, and then be left wondering a week later when the project is back at square one.
We are very far away from "unfixable" performance issues pretty much everywhere, except perhaps in the demo scene with hand written assembly code and in some shader code running on GPUs.
In theory you're right. In real life, it's unlikely that the developers who were (probably barely) able to implement the system in a high-level language are able to rewrite and it in assembly code. And even if they were, unless you don't intend to change the code ever again, it's more likely you're just piling up technical debt.
Assembly isn't a good example, there are plenty of high level languages which produce excellent compiled output. But you have to use those, not any fancy new language or framework.
But your point is correct in that in many projects there isn't enough budget to make the product faster. Which is a project management decisions, not that the speed issues are unfixable.
But your point is correct in that in many projects there isn't enough budget to make the product faster. Which is a project management decisions, not that the speed issues are unfixable.
Are you seriously suggesting that there's no improvement to be had in the typical ui without rewriting in assembly?
that was not the case, I ended being the one plotting the flame charts as no-one wanted to do it
Similar experience as a PM and as a technical director: the vast majority of devs, outside maybe 3d rendering or HPC, do not understand nor care about performance optimization.
Implementing some feature, fixing a bug, refactoring code to improve DX? Sure, happy to do, you don’t even have to ask. Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans? No chance, unless the PM forces the matter.
My hope is that some of that can be taught and embedded into the team culture, but the reality is that day-to-day web development is simply too far abstracted from the underlying software and hardware, and getting your average javascript programmer to care about milliseconds is an uphill battle.
The sad thing is that users do definitely care, and the evidence shows up again and again: user behaviour tests for 100ms vs 500ms responses, the reviews of the new M1 processors, ...
Implementing some feature, fixing a bug, refactoring code to improve DX? Sure, happy to do, you don’t even have to ask. Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans? No chance, unless the PM forces the matter.
My hope is that some of that can be taught and embedded into the team culture, but the reality is that day-to-day web development is simply too far abstracted from the underlying software and hardware, and getting your average javascript programmer to care about milliseconds is an uphill battle.
The sad thing is that users do definitely care, and the evidence shows up again and again: user behaviour tests for 100ms vs 500ms responses, the reviews of the new M1 processors, ...
> Plotting tail response times, flame charts, allocation pressure, DOM changesets, database execution plans?
Is anybody even teaching people these things? I do the above as a matter of course, but I've learned how and why through osmosis, over the years, mostly because I dabble with gamedev as a hobby (and because I care about performance). None of that was covered in any of my university courses. And, out of the people I worked with, I was and am literally the only one who knows how to do any of that.
Is anybody even teaching people these things? I do the above as a matter of course, but I've learned how and why through osmosis, over the years, mostly because I dabble with gamedev as a hobby (and because I care about performance). None of that was covered in any of my university courses. And, out of the people I worked with, I was and am literally the only one who knows how to do any of that.
You hit a vein of truth here, I don't recall any of that being covered in a university course or in any of the companies I've worked with. My knowledge too comes from dabbling with gamedev, programming/hacking underpowered hardware (90's consoles), and spending (too much) time on open-source projects where performance optimization mattered.
I don't expect my colleagues to have the same kind of experience, but I would expect someone presenting as a "senior frontend engineer" to understand the GC impact of allocating thousands of objects in a tight computation loop; or of doing heavy computations / updating the DOM inside a mouse move event handler.
On the other hand, Slack is worth $27.7B and is still selling a product that has frustrating multi-second delays on standard keyboard interactions, so I don't know. Maybe I am really just expecting too much.
I don't expect my colleagues to have the same kind of experience, but I would expect someone presenting as a "senior frontend engineer" to understand the GC impact of allocating thousands of objects in a tight computation loop; or of doing heavy computations / updating the DOM inside a mouse move event handler.
On the other hand, Slack is worth $27.7B and is still selling a product that has frustrating multi-second delays on standard keyboard interactions, so I don't know. Maybe I am really just expecting too much.
That raises an important question, though: is it really true that the developers don't care? Or is it more a matter of these performance improvements falling to the wayside because management pushes features and/or bugfixes first?
I've definitely seen both in the wild, so it's an important question to ask every time, rather than sticking to a blanket assumption of "devs neither understand nor care about performance optimization".
I've definitely seen both in the wild, so it's an important question to ask every time, rather than sticking to a blanket assumption of "devs neither understand nor care about performance optimization".
That can definitely be the case. In our case, we sometimes have MR's that specifically mention things like "I did X as a shortcut to get this running, we will have to optimize this before we can do Y", which are totally fine and laudable.
However, we also have MR's where e.g. moving the mouse causes jank / slows updates down to <20 fps. Doing a paired review on those leads to the observations above: many developers simply don't know how to measure and optimize code, and even less how to estimate impact before writing that code. It would be easy to dismiss this as "bad developers", but I've seen it so many times over the last two decades that I think it runs deeper than that.
And then we all end up on HN with our favourite complaint: slow bloated Electron apps - except VSCode which is fast. The problem is not Electron, it's a systematic lack of knowledge and incentives about performance in the field.
However, we also have MR's where e.g. moving the mouse causes jank / slows updates down to <20 fps. Doing a paired review on those leads to the observations above: many developers simply don't know how to measure and optimize code, and even less how to estimate impact before writing that code. It would be easy to dismiss this as "bad developers", but I've seen it so many times over the last two decades that I think it runs deeper than that.
And then we all end up on HN with our favourite complaint: slow bloated Electron apps - except VSCode which is fast. The problem is not Electron, it's a systematic lack of knowledge and incentives about performance in the field.
> slow bloated Electron apps - except VSCode which is fast
Is it, though? I'll give VSCode credit for being better than your average Electron app, but it (and Azure Data Studio, which last I checked is based on VSCode) ain't exactly a speed demon, either. Then again, I'm typically running something like Emacs, which is a lot lighter-weight (at least before I blow up ~/.emacs.d), so I'm probably just spoiled :)
It's certainly faster than Visual Studio, but it also has far fewer features.
Is it, though? I'll give VSCode credit for being better than your average Electron app, but it (and Azure Data Studio, which last I checked is based on VSCode) ain't exactly a speed demon, either. Then again, I'm typically running something like Emacs, which is a lot lighter-weight (at least before I blow up ~/.emacs.d), so I'm probably just spoiled :)
It's certainly faster than Visual Studio, but it also has far fewer features.
> And then we all end up on HN with our favourite complaint: slow bloated Electron apps - except VSCode which is fast. The problem is not Electron, it's a systematic lack of knowledge and incentives about performance in the field.
Has anyone ever done an analysis of what exactly VSCode does differently than a typical Electron app? Where it deviates from the garden path?
Has anyone ever done an analysis of what exactly VSCode does differently than a typical Electron app? Where it deviates from the garden path?
Can't say anything about this particular case but one possible cause is that the devs have looked around, seen which behaviours are likely to result in promotion/pay raises and have determined that performance work is not one of them.
[deleted]
When the topic of bloat comes up, I often point out that it's only a problem in certain software domains. High-performance game engines must (by definition) be performance-competitive or they'll be out of business. They don't bloat in the way messaging applications have over the decades.
the onus should be upon not surrounding yourself with the latest technology - supporting old hardware and upcycling computers.
here in my city I can pull out a sticky mud-encrusted motherboard and GPU from the flea markets - scrub it down with a bit of isopropyl alcohol, and put together something as responsive as a 2015 macbook air for 20 euro (PopOS is a favourite for this).
in an agency, you have an MBP thrust upon you, and your software “works fine on [our] computers”. end users still be running a last generation of CPU will eventually decide “I need a new computer”, and the cycle is complete.
its not that developers dont care, its that they’re never given the chance to care under these ... circumstances.
here in my city I can pull out a sticky mud-encrusted motherboard and GPU from the flea markets - scrub it down with a bit of isopropyl alcohol, and put together something as responsive as a 2015 macbook air for 20 euro (PopOS is a favourite for this).
in an agency, you have an MBP thrust upon you, and your software “works fine on [our] computers”. end users still be running a last generation of CPU will eventually decide “I need a new computer”, and the cycle is complete.
its not that developers dont care, its that they’re never given the chance to care under these ... circumstances.
There are cases of dev teams intentionally limiting themselves - Microsoft Windows Mobile OS developers having last gen devices (200 Mhz in times when flagships were 3x faster), Google web devs developing on a proxy which simulates developing country internet (low speed, high packet loss and jitter).
A common believe among my non developer friends is that apple does it on purpose so their users need to keep buying new hardware. I don't know if they do, but at least their incentive is not very big to keep old devices running smooth.
[deleted]
Apple and Samsung have both paid fines and settlements recently because of deliberately slowing down older devices - most recently Apple in November: https://finance.yahoo.com/news/apple-u-states-reach-113-1804...
This was done to keep the device from restarting in scenarios where degraded batteries were unable to supply enough power. It wasn't a nefarious scheme to get users to upgrade.
Wasn't the problem that they did it on devices which were out of warranty and could not even get their batteries exchanged (at least not for a reasonable price)? Which in turn resulted in permanently degraded performance on otherwise usable products.
It didn't trigger based on warranty, it was specific circumstances. If an in-warranty battery was sufficiently degraded, it would trigger the throttling, and an out of warranty device with a healthy battery wouldn't.
> This performance management works by looking at a combination of the device temperature, battery state of charge, and battery impedance. Only if these variables require it, iOS will dynamically manage the maximum performance of some system components, such as the CPU and GPU, in order to prevent unexpected shutdowns.
https://support.apple.com/en-us/HT208387
> This performance management works by looking at a combination of the device temperature, battery state of charge, and battery impedance. Only if these variables require it, iOS will dynamically manage the maximum performance of some system components, such as the CPU and GPU, in order to prevent unexpected shutdowns.
https://support.apple.com/en-us/HT208387
This can be viewed as a battery defect, especially if it's not user replaceable. Battery usable capacity vs longevity is a tradeoff in how the BMS in configured.
a) Prosecutors in the US and EU allege that both Apple and Samsung did in fact participate in a nefarious scheme to get users to upgrade. I realize that Apple and Samsung say they didn’t do that but I don’t think they are being honest. This thing where tech workers take tech companies at face value when said companies have repeatedly demonstrated their dishonesty is... really something.
b) At any rate, “Apple deceitfully handicapped older products to cover up a more serious (but fixable) flaw, knowingly pushing customers into unnecessary upgrades” is really not any better than “Apple deceitfully handicapped older devices to push consumers into unnecessary upgrades.”
b) At any rate, “Apple deceitfully handicapped older products to cover up a more serious (but fixable) flaw, knowingly pushing customers into unnecessary upgrades” is really not any better than “Apple deceitfully handicapped older devices to push consumers into unnecessary upgrades.”
I don't see why we should take prosecutors (who have their own goals and ambitions, operating in a political environment) at face value either. There's little to lose in pursuing a company with deep pockets, and a lot to gain.
I would call this “being so skeptical that your brain falls out” since you could make the same argument (about either politics or money) with scientists, human rights advocates, programmers, etc. “Actually you can’t trust anybody and all viewpoints are equally suspect” isn’t as enlightened as you think.
In this specific case Apple and Samsung have been proven dishonest and manipulative, and they have a far stronger legal/financial incentive to lie than separate groups of prosecutors in the US and many separate EU member states. I also find a conspiracy internal to Apple/Samsung much more plausible than a conspiracy across attorneys general from 34 US states.
In this specific case Apple and Samsung have been proven dishonest and manipulative, and they have a far stronger legal/financial incentive to lie than separate groups of prosecutors in the US and many separate EU member states. I also find a conspiracy internal to Apple/Samsung much more plausible than a conspiracy across attorneys general from 34 US states.
> “Actually you can’t trust anybody and all viewpoints are equally suspect” isn’t as enlightened as you think.
Only trusting viewpoints that agree with your personal biases isn't enlightened, either.
> "In this specific case Apple and Samsung have been proven dishonest and manipulative"
is an unvarnished falsehood. The throttling wasn't across the board, it was triggered in specific circumstances related to the state of the battery. There was never any evidence that this was a scheme to defraud customers.
Only trusting viewpoints that agree with your personal biases isn't enlightened, either.
> "In this specific case Apple and Samsung have been proven dishonest and manipulative"
is an unvarnished falsehood. The throttling wasn't across the board, it was triggered in specific circumstances related to the state of the battery. There was never any evidence that this was a scheme to defraud customers.
This was an attempt to save the battery. Where Apple messed up was not talking about this feature.
I'm a bit tired of this Apple apologism. Do you think that a corporation with their market cap is not fully aware of these kinds of decisions that impact their sales?
This is the same company that removed the headphone jack for very cynical reasons, in order to increase the sale price of their phone by $150 (or however much the Airpods cost). The same company that repeatedly removed ports from the laptops in order to sell more dongles (so much so that there were running gags at the time about Apple, the dongle company). A company where the revenue from the sale of accessories for their devices could literally make a Fortune 1000 company (!!!).
They definitely knew what they were doing and chose to do the thing that most benefited their bottom line.
Let's stop giving the benefit of the doubt to the top tech companies. They don't deserve it like mom and pop stores.
Oblio's Law: Never attribute to malice that which can be attributed to stupidity, unless the ones acting have an army of data scientists, researchers, market analysts and PR people at their disposal.
This is the same company that removed the headphone jack for very cynical reasons, in order to increase the sale price of their phone by $150 (or however much the Airpods cost). The same company that repeatedly removed ports from the laptops in order to sell more dongles (so much so that there were running gags at the time about Apple, the dongle company). A company where the revenue from the sale of accessories for their devices could literally make a Fortune 1000 company (!!!).
They definitely knew what they were doing and chose to do the thing that most benefited their bottom line.
Let's stop giving the benefit of the doubt to the top tech companies. They don't deserve it like mom and pop stores.
Oblio's Law: Never attribute to malice that which can be attributed to stupidity, unless the ones acting have an army of data scientists, researchers, market analysts and PR people at their disposal.
> They definitely knew what they were doing and chose to do the thing that most benefited their bottom line.
Imho there's a reasonable case that they did the thing which best protected users older devices and daily usable time, and I think most users would prefer their phone stays working for a day on a single charge, so they can make and receive calls and messages towards the end of the day.
It's possible Apple wasn't thinking of the users, but it's not a clear cut case.
It's also possible that if Apple hadn't slowed the older phones down as batteries wore out, they would have seen more sales as users needed to replace their phones more urgently as battery life dropped. So it's not obvious that the action they took favoured sales anyway.
Imho there's a reasonable case that they did the thing which best protected users older devices and daily usable time, and I think most users would prefer their phone stays working for a day on a single charge, so they can make and receive calls and messages towards the end of the day.
It's possible Apple wasn't thinking of the users, but it's not a clear cut case.
It's also possible that if Apple hadn't slowed the older phones down as batteries wore out, they would have seen more sales as users needed to replace their phones more urgently as battery life dropped. So it's not obvious that the action they took favoured sales anyway.
> It's possible Apple wasn't thinking of the users, but it's not a clear cut case.
Court cases are rarely won, especially with big companies. They have the money to drag them out so most are just settled. So in my eyes any class action lawsuit a company settles for millions is a case they lost.
When will you admit that it was a clear case? They just admitted it themselves by settling!
I give up :-)
Court cases are rarely won, especially with big companies. They have the money to drag them out so most are just settled. So in my eyes any class action lawsuit a company settles for millions is a case they lost.
When will you admit that it was a clear case? They just admitted it themselves by settling!
I give up :-)
The new iPhone (12? 13? 293?) comes without an AC adapter.
Because that is good for the environment :)
Because that is good for the environment :)
Even before that, people observed phones just get slower over time and with enough OS updates. An OS update should never make things feel slower or less responsive, yet here we are.
[deleted]
There is another aspect: Game engine developers tend to use high-end hardware during development, because they anticipate that next years hardware will be stronger. While there is certainly some truth to it, mostly the effect is not as strong as the developers hope it is.
I subscribe to the theory that Moore’s Law was in part a self-fulfilling prophecy, in that the expectation that transistor density should double every two years led to product roadmaps that aimed to hit that target.
If only we could popularize an analogous law for software performance…
If only we could popularize an analogous law for software performance…
Yup. And the result of this algorithm is of course that the software is always barely usable.
For optimization look into computer networking, that's where all the competing-for-lower-latency-programmers hang out, developing routers and switches.
Totally this
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).
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).
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.
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.
Yes. And the resulting churn and dissatisfaction is mostly invisible, unless you go looking for it. Most users don't even file bug reports when things are actually broken. Most users can't tell why they don't like something when it just runs slowly. Even technical users will almost never file bug reports against slow and janky performance.
I hate Jira - but I think the main reason is just that it feels slow to use. A slow UI gives a visceral felt sense of lethargy / sickness, which I associate with the product. Is that a bug? I don't know. But I bet it runs fast enough internally at atlassian. And I suspect the PMs at atlassian tell themselves the same story - that its not worth the development time to make it fast. And that might match with the feedback they get, because all the users who care about that have probably already bounced to other products.
I hate Jira - but I think the main reason is just that it feels slow to use. A slow UI gives a visceral felt sense of lethargy / sickness, which I associate with the product. Is that a bug? I don't know. But I bet it runs fast enough internally at atlassian. And I suspect the PMs at atlassian tell themselves the same story - that its not worth the development time to make it fast. And that might match with the feedback they get, because all the users who care about that have probably already bounced to other products.
Jira is bad for a completely different reason. Jira is bad because Atlassian has grown from a company that sold software to its users, to a company that sells software to people who work in corporate procurement. Atlassian only has to impress two people to make a sale now. The person box ticking the features, and the person who wants to see the reports that it produces, and neither of those people are the ones who actually use the software.
I worked at a company where they used a time tracking application (most of their revenue was T+M) which was so bad that one of the developers reverse engineered the front end API and built a new front end for it.
What you said about impressing the person viewing the reports really rings true in that case.
What you said about impressing the person viewing the reports really rings true in that case.
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.
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.
> people don’t want to use their improvements to improve speed
I don't agree. It's only software developers that think that way with their latest gadgets, fast internet at high tech buildings; not the users.
I don't agree. It's only software developers that think that way with their latest gadgets, fast internet at high tech buildings; not the users.
Users tend not to think about these sort of trade offs at all. Users will also complain about not having the features they want just as readily as they will complain about something being slow.
But that’s really besides the point. As long as an application is fast enough that a user doesn’t notice a problem with it, then you’re done optimizing for performance (in most cases at least). So if new hardware comes out that’s twice as fast, you could very sensibly keep the performance at the same acceptable level, and use the new performance budget in other ways. Such as by introducing various inefficiencies via abstractions that make feature development faster.
But that’s really besides the point. As long as an application is fast enough that a user doesn’t notice a problem with it, then you’re done optimizing for performance (in most cases at least). So if new hardware comes out that’s twice as fast, you could very sensibly keep the performance at the same acceptable level, and use the new performance budget in other ways. Such as by introducing various inefficiencies via abstractions that make feature development faster.
The issue is that not all users can buy that new hardware that’s twice as fast.
This is just a further misunderstanding of the market. People optimize for who their customers are. Knowing what devices your code runs on is trivially easy, and so is measuring its performance against them. People aren’t going to instantaneously make their code 20x slower just because the new Apple chip is so good. But they’re also not going to optimize for that old Samsung phone that represent 0.0003% of their user base.
You're really projecting if you think normal people give a crap about expensive abstractions or even speed of development.
Most of those "abstractions" and "development" are working against the user anyway: most webpages have not added features in more than 20 years but still require more power because developers can't get their shit together.
Speed is the reason people bought SSDs. It's the whole core of Apple's M1 Marketing. It's probably the biggest reason why people buy new computers. Lack of speed is the reason I had to throw away my Smart TV after 8 years of useless upgrades.
People pay more for faster internet because they want more movies in bigger quality or to download big things faster. Not because they give a crap about your shitty app.
> Unless you have a performance issue that’s really pathological, speed really doesn’t matter for most applications
And that's only true because developers are constantly forcing hardware developers and customers to throw money at the problem.
Most of those "abstractions" and "development" are working against the user anyway: most webpages have not added features in more than 20 years but still require more power because developers can't get their shit together.
Speed is the reason people bought SSDs. It's the whole core of Apple's M1 Marketing. It's probably the biggest reason why people buy new computers. Lack of speed is the reason I had to throw away my Smart TV after 8 years of useless upgrades.
People pay more for faster internet because they want more movies in bigger quality or to download big things faster. Not because they give a crap about your shitty app.
> Unless you have a performance issue that’s really pathological, speed really doesn’t matter for most applications
And that's only true because developers are constantly forcing hardware developers and customers to throw money at the problem.
Yes. I would assume that the only metrics that count for CPU engineers are performance, power consumption and cost. Features are not a relevant metric. What was the last CPU feature that was not added to improve performance? Virtualization support?
Security mitigations for side channel attacks?
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.
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.
In theory yes, but at the same time, are we as software developers really more time-efficient as we used to be?
I mean I'm still writing CRUD software ten years later; the tools have changed from idk, jquery mobile and php to React and go, but I don't feel any faster doing it. I want to say that things like form validation are faster and easier now, but no, they've just been reinvented a few times with changing underlying technology. I want to say that they solved the ORM problem, but nope, still crap, and again because of having to re-invent the wheel for a new language, environment, and generation of developers. Did the existing tools and languages improve much? Also no, at least not that I know of, still wouldn't use Hibernate if I can help it.
So in many ways things feel like they have advanced, but at least speaking for myself, at the same time things feel like they are still the same.
At least for the moment my Go application recompiles / restarts much faster than the old Java / Spring applications I used to work with. Which puts it on par with the PHP experience from before that.
I mean I'm still writing CRUD software ten years later; the tools have changed from idk, jquery mobile and php to React and go, but I don't feel any faster doing it. I want to say that things like form validation are faster and easier now, but no, they've just been reinvented a few times with changing underlying technology. I want to say that they solved the ORM problem, but nope, still crap, and again because of having to re-invent the wheel for a new language, environment, and generation of developers. Did the existing tools and languages improve much? Also no, at least not that I know of, still wouldn't use Hibernate if I can help it.
So in many ways things feel like they have advanced, but at least speaking for myself, at the same time things feel like they are still the same.
At least for the moment my Go application recompiles / restarts much faster than the old Java / Spring applications I used to work with. Which puts it on par with the PHP experience from before that.
Which basically sums up what Alan Kay describe as Reinventing the Flat Tires.
And it felt especially true in the field of Web Technologies.
>at the same time things feel like they are still the same.
In the past few years I have always felt things are far too complex. We just didn't make anything simpler.
And it felt especially true in the field of Web Technologies.
>at the same time things feel like they are still the same.
In the past few years I have always felt things are far too complex. We just didn't make anything simpler.
This is a very good point. In many ways I feel we're optimizing complexity without solving any old problems.
We invent new problems to solve, and we do solve them, but still are left with the same old problems.
We invent new problems to solve, and we do solve them, but still are left with the same old problems.
This is what I see and hear from web developers all the time. It sounds terrible.
As a graphics programmer I feel things have moved very far in the right direction within the last ten years.
I used to write generic computations disguised as pixel rendering without any decent tools for diagnostics or profiling.
Now I can just use a compute shader and if I want to debug or profile it there are so many great alternatives.
I recently re-implemented a particle simulation I first wrote in 2011. Without access to the pervious code.
The first time around it took me months. Now it took me days. Sure, I've learned a lot since, but a lot of the speedup was just from better language and tool support for what I wanted to do.
As a graphics programmer I feel things have moved very far in the right direction within the last ten years.
I used to write generic computations disguised as pixel rendering without any decent tools for diagnostics or profiling.
Now I can just use a compute shader and if I want to debug or profile it there are so many great alternatives.
I recently re-implemented a particle simulation I first wrote in 2011. Without access to the pervious code.
The first time around it took me months. Now it took me days. Sure, I've learned a lot since, but a lot of the speedup was just from better language and tool support for what I wanted to do.
> I want to say that things like form validation are faster and easier now, but no
I’d actually say forms are more of a pain in an SPA than they are with server rendering.
You have to track the state of every field so input doesn’t get clobbered on a re-render, which isn’t difficult but can be pretty tedious, especially if it’s a very dynamic form. And if you want native input attributes like `required` to work you need to still do a native form submission, but then intercept it and do your AJAX request or whatever instead.
The only part that’s really easier is handling server-side validation errors, because instead of trying to re-construct the populated form using the submitted input, you can just leave it all on screen.
I’d actually say forms are more of a pain in an SPA than they are with server rendering.
You have to track the state of every field so input doesn’t get clobbered on a re-render, which isn’t difficult but can be pretty tedious, especially if it’s a very dynamic form. And if you want native input attributes like `required` to work you need to still do a native form submission, but then intercept it and do your AJAX request or whatever instead.
The only part that’s really easier is handling server-side validation errors, because instead of trying to re-construct the populated form using the submitted input, you can just leave it all on screen.
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.
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.
This is one of the aspects where optimizations starts making sense again.
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.
Of course, they will seek to optimize the software they run on their own servers :)
[deleted]
> but it is really hard to sell this kind of software.
It's hard to sell software just on speed, but it is an integral part of good UX (that feeling of a good, light weight, robust piece of software that is there to help instead of hinder). I for one desire that a lot and I think many others do too (see the success of Apple).
It's hard to sell software just on speed, but it is an integral part of good UX (that feeling of a good, light weight, robust piece of software that is there to help instead of hinder). I for one desire that a lot and I think many others do too (see the success of Apple).
> 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
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
And Safari Story from Don Melton
https://donmelton.com/2013/01/10/safari-is-released-to-the-w...
https://donmelton.com/2013/01/10/safari-is-released-to-the-w...
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.
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.
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.
Why? There's a lot of stuff getting developed with web technology as the platform of choice. Not because developers want to, but because major stakeholders are pushing for it. It enables cross-device deployment without gatekeeping by platform holders and crusty IT departments. Making the platform worse just makes these applications worse, it won't turn them into pristine native applications.
WebAssembly support is there, but it needs SIMD and threads to really be fast. That could happen soon, now that there’s some consensus on the standards for both.
WebGL2 support is just about ready in Safari. They are just about fully moved over to using ANGLE as the WebGL backend which includes WebGL2 support. I tested it out with my app on the Safari Technology Preview and it was flawless (as expected from using ANGLE in Chrome).
WebGL2 support is just about ready in Safari. They are just about fully moved over to using ANGLE as the WebGL backend which includes WebGL2 support. I tested it out with my app on the Safari Technology Preview and it was flawless (as expected from using ANGLE in Chrome).
> 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.
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.
> 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.
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.
"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
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).
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...
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...
> 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.
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.
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.
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.
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).
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).
> 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.
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.
> 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.
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.
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.)
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.)
> ... but accomplishing much more. Easiest example is game software.
Ha! Are you saying the old games that ran faster didn't bring us joy?
Ha! Are you saying the old games that ran faster didn't bring us joy?
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
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.
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.
Try using a 20-year-old machine, even a freshly installed machine running contemporaneous software is painfully slow compared to a modern econobox.
No need for contemporaneous software, for many people a 20-year-old office of some kind is more than enough, plus email. :)
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.
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.
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.
No, I have my pretty new work laptop as a comparison. Maybe I'm just not using any really resource-hungry new software.
With as recent of a phenomenon as bloated software feels, I was shocked to see the 1995 date on this quote
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
I think that's part of the argument for this, yes–a company that doesn't provide their developers with the best tooling is hurting themselves because they're wasting their developer's time. But I'll argue that the opposite can be true as well! By using a machine that is far removed from what your customers are on, can you really test their user experience?
And, this is a personal anecdote of course, but sometimes having fast machines can paper over problems that you should really be addressing: I had a coworker once who temporarily used a fairly (~7 years) old machine to do their development work until they could get something newer to work on. During that time I noticed that they would take a while to make minor fixes after reviews. I asked them why and they told me that they would make the change and then they'd build it and it was taking dozens of minutes–it turns out that there was a creeping dependency tracking issue in the build process that nobody had bothered to address yet because it didn't seem like a huge issue on our normal machines. But fixing it certainly got his turnaround time way up, and the CI machines really liked the change too ;)
And, this is a personal anecdote of course, but sometimes having fast machines can paper over problems that you should really be addressing: I had a coworker once who temporarily used a fairly (~7 years) old machine to do their development work until they could get something newer to work on. During that time I noticed that they would take a while to make minor fixes after reviews. I asked them why and they told me that they would make the change and then they'd build it and it was taking dozens of minutes–it turns out that there was a creeping dependency tracking issue in the build process that nobody had bothered to address yet because it didn't seem like a huge issue on our normal machines. But fixing it certainly got his turnaround time way up, and the CI machines really liked the change too ;)
Why would a developer be in charge of testing the user experience from the user perspective? Either have good relations with your end users or use QA with properly outfit machines.
Or you should -know- what specs your users are using (this is really not hard) and optimize for that.
You can get chrome to degrade network performance etc. It's not easy to downgrade machine performance tho.
Or you should -know- what specs your users are using (this is really not hard) and optimize for that.
You can get chrome to degrade network performance etc. It's not easy to downgrade machine performance tho.
> Why would a developer be in charge of testing the user experience from the user perspective?
I can count on one hand the number of companies I've worked at in the last decade who had in-house QA teams. Most companies just rely on the developers to test their (our) own code. The exceptions are banks, gamedev companies and big corp products (like Windows).
Most web software I've seen - especially in the startup world - just assumes that "it works well enough on the developers' specced out mac" means it works. The most tragic version of this I saw was our app looking awful on a ‘normal’ 19” desktop monitor. The problem was our designers did all their work from 27" imacs. They never thought to design and test on smaller displays. Or the designers placing adjacent colors that look great on color graded displays but are almost indistinguishable on the trashy 6 bit TN displays that were ubiquitous in offices a few years ago.
Even in companies with dedicated QA I haven't seen many tickets of the form of "the program runs slowly on this old computer we have". Sadly the creeping performance rot is mostly invisible.
I can count on one hand the number of companies I've worked at in the last decade who had in-house QA teams. Most companies just rely on the developers to test their (our) own code. The exceptions are banks, gamedev companies and big corp products (like Windows).
Most web software I've seen - especially in the startup world - just assumes that "it works well enough on the developers' specced out mac" means it works. The most tragic version of this I saw was our app looking awful on a ‘normal’ 19” desktop monitor. The problem was our designers did all their work from 27" imacs. They never thought to design and test on smaller displays. Or the designers placing adjacent colors that look great on color graded displays but are almost indistinguishable on the trashy 6 bit TN displays that were ubiquitous in offices a few years ago.
Even in companies with dedicated QA I haven't seen many tickets of the form of "the program runs slowly on this old computer we have". Sadly the creeping performance rot is mostly invisible.
I worked at an education tech startup so we were mildly aware of our app being run on slowly performing computers. Low bandwith conditions were more of the worry tho.
Honestly, people running slow computers are probably just used to poor performance. I fully agree with you that we should do something about it but I don't see that happening unless it's a strong priority (feature X/y/z or performance? is usually the conversation).
Anecdotally: I'll never forget the first time I launched an app from an SSD and vowed I was never going back.
Honestly, people running slow computers are probably just used to poor performance. I fully agree with you that we should do something about it but I don't see that happening unless it's a strong priority (feature X/y/z or performance? is usually the conversation).
Anecdotally: I'll never forget the first time I launched an app from an SSD and vowed I was never going back.
You can simulate a slower machine with a VM, or by disabling extra cores and memory on your dev machine, or by running your app off a slow external drive.
It's not as easy to do this as it could be, but it's not that hard either.
It's not as easy to do this as it could be, but it's not that hard either.
Why would a developer be in charge of testing the user experience from the user perspective? Either have good relations with your end users or use QA with properly outfit machines.
It doesn’t have to be either/or, it can be both. Developers absolutely should be using their own software frequently, seeing and feeling how well it performs; trying it out on a lower-spec machine is always a useful exercise.
That doesn’t mean you can’t also have dedicated QA. Developers shouldn’t have to be in charge of QA, but they should have some involvement.
It doesn’t have to be either/or, it can be both. Developers absolutely should be using their own software frequently, seeing and feeling how well it performs; trying it out on a lower-spec machine is always a useful exercise.
That doesn’t mean you can’t also have dedicated QA. Developers shouldn’t have to be in charge of QA, but they should have some involvement.
Simply run your app in a VM, that should degrade performance, customizable as well.
I'm not really buying that. You can limit ram access but even at a single core i7 you're going to have better JS performance than some i3 from 10 years ago.
Hypervisor / virtualization tech should mean you get very close to actual host OS performance. Otherwise this whole container thing wouldn't work so hot?
Hypervisor / virtualization tech should mean you get very close to actual host OS performance. Otherwise this whole container thing wouldn't work so hot?
> It's not easy to downgrade machine performance tho.
yes > /dev/null &
That and the cost of distractions waiting for a build. I used to work in a place where a build would take 3-4 minutes. In practice, it often took 15 as I went to Reddit or Hacker News or chatted with a co-worker and then had to remember what it was I was doing.
I think one needs to differentiate between building and manually testing the app. Running the build on a fast machine greatly benefits the development cycle while the tests are harmed because you don't test close to your users.
There used to be a time when you ran development/debugger on a different machine than the one running the application. Developers having fast machines for work should have absolutely nothing to do with not properly testing for user environments. That's just poor engineering, which unfortunately pervades today.
This is still the case in mobile development. A good setup is to build on a fast expensive PC and run your app on an old cheap phone.
Your job is to make cost effective decisions actually. And that’s a long game not a short game.
If you fail to make those consistently you end up with large infrastructure bills and unhappy customers eventually.
If you fail to make those consistently you end up with large infrastructure bills and unhappy customers eventually.
> Your job isn't to build the smoothest, most optimized, experience for your customers.
That is literally my job! You should have someone like that too, or else you'll end up shipping an Electron app like Discord does.
That is literally my job! You should have someone like that too, or else you'll end up shipping an Electron app like Discord does.
> [...] or else you'll end up shipping an Electron app like Discord does.
And get to dominate their market niche?
People got to realize while native apps are nice and all, there is absolutely zero evidence that going native vs cross-platform improves any metric a business actually cares about. Users are flocking to cross-platform apps in droves!
Vocal message board users screaming their preference for native apps are not in any way a significant share of the actual market for these applications.
And get to dominate their market niche?
People got to realize while native apps are nice and all, there is absolutely zero evidence that going native vs cross-platform improves any metric a business actually cares about. Users are flocking to cross-platform apps in droves!
Vocal message board users screaming their preference for native apps are not in any way a significant share of the actual market for these applications.
> Users are flocking to cross-platform apps in droves!
I seriously doubt the use of Electron is what's driving that.
And it's also worth remembering that "cross-platform" ≠ "bundle an entire web browser in the app". Qt exists, as one of many examples of application frameworks/toolkits that are simultaneously cross-platform and native.
I seriously doubt the use of Electron is what's driving that.
And it's also worth remembering that "cross-platform" ≠ "bundle an entire web browser in the app". Qt exists, as one of many examples of application frameworks/toolkits that are simultaneously cross-platform and native.
> I seriously doubt the use of Electron is what's driving that.
It is indirectly driving that.
Using Electron instead of other cross-platform frameworks like Qt allows one to work faster since you can apply webdev knowledge, and that directly leads to features that users actually care about being delivered faster.
It is indirectly driving that.
Using Electron instead of other cross-platform frameworks like Qt allows one to work faster since you can apply webdev knowledge, and that directly leads to features that users actually care about being delivered faster.
Okay, and what good are those features if users are afraid to run the app lest it eat all their RAM for breakfast?
Like, if you just need to spit out a prototype to hit the ground running fast, then fine, but long-term there are pretty clear benefits to using the right tool for the job.
The "work faster" argument is pretty dubious on its own anyway; yeah, maybe web devs ain't particularly productive with Qt or similar frameworks, but desktop devs absolutely can (and arguably should) be productive with such a framework.
Like, if you just need to spit out a prototype to hit the ground running fast, then fine, but long-term there are pretty clear benefits to using the right tool for the job.
The "work faster" argument is pretty dubious on its own anyway; yeah, maybe web devs ain't particularly productive with Qt or similar frameworks, but desktop devs absolutely can (and arguably should) be productive with such a framework.
> Okay, and what good are those features if users are afraid to run the app lest it eat all their RAM for breakfast?
There is no evidence to believe that users are concerned about RAM usage to any level that would move them over to competing apps.
> The "work faster" argument is pretty dubious on its own anyway; yeah, maybe web devs ain't particularly productive with Qt or similar frameworks, but desktop devs absolutely can (and arguably should) be productive with such a framework.
There are orders of magnitude more web devs than devs who are even just familiar with desktop GUI toolkits. Even if you can find people who are just as productive with (for example) Qt, they'd be (way) more expensive than the average web dev.
And, again, now you have less budget to spend on things that actually gets you users.
There is no evidence to believe that users are concerned about RAM usage to any level that would move them over to competing apps.
> The "work faster" argument is pretty dubious on its own anyway; yeah, maybe web devs ain't particularly productive with Qt or similar frameworks, but desktop devs absolutely can (and arguably should) be productive with such a framework.
There are orders of magnitude more web devs than devs who are even just familiar with desktop GUI toolkits. Even if you can find people who are just as productive with (for example) Qt, they'd be (way) more expensive than the average web dev.
And, again, now you have less budget to spend on things that actually gets you users.
Discord just hit 100 million active monthly users, kind of proving OP's point. Using Electron enabled them to ship quickly and deliver on important features to users.
What about Cloud Environment?
Do you know that writing code efficiently can also save money for the company? If you try to write code that burns bandwidth or CPU cycles without even attempting to optimize it, it's gonna cost you an eye at the end of the year.
Software optimized for the slowest hardware possible actually does saves money, which helps also to reach the goal of doing more money, since more hardware is being supported, not only the cutting-edge one.
I've seeing now this infamous trend also on Android Phones boosting 90-120 Hz screens. If applications get optimized to run on these phones, whose CPU is also strong, obviously older phones are suffering and become sluggish.
Seriously, try to write code as your target platform is a Raspberry Pi 1 model. If works on it fast, it's going to be fast everywhere
Do you know that writing code efficiently can also save money for the company? If you try to write code that burns bandwidth or CPU cycles without even attempting to optimize it, it's gonna cost you an eye at the end of the year.
Software optimized for the slowest hardware possible actually does saves money, which helps also to reach the goal of doing more money, since more hardware is being supported, not only the cutting-edge one.
I've seeing now this infamous trend also on Android Phones boosting 90-120 Hz screens. If applications get optimized to run on these phones, whose CPU is also strong, obviously older phones are suffering and become sluggish.
Seriously, try to write code as your target platform is a Raspberry Pi 1 model. If works on it fast, it's going to be fast everywhere
That's true, but it really depends a lot on the kind of software you're writing. If you're Google or Facebook and make fractions of a cent per pageview despite doing an enormous amount of computation then optimizing your code and infrastructure is very important indeed. On the other hand someone like Airbnb is very likely to make tens or hundreds of dollars off a handful of pageviews, so cloud costs are much less of a concern.
In my first job, management purposely prohibited developers from using really powerful machines because we needed to make the software faster. The problem was it was hard to make the software faster because it was so slow to run, measure, and verify changes.
Those managers were eventually all let go and one of the first things new management did was buy us the most powerful machines they could find and institute performance regression tests that rachetted down. Each change could only keep the existing performance or make it faster. And changes that made it faster set the new watermark. Regressions required management approval.
After performance having been unimproved for a year, it was largely resolved in 6 months.
Since then I’ve been a believer that you give your developers nearly the fastest platform money can buy but then have automated, gatekeeping tests for your lowest target platform, with spot checking to make sure your tests reflect actual user experienced performance on that platform.
Those managers were eventually all let go and one of the first things new management did was buy us the most powerful machines they could find and institute performance regression tests that rachetted down. Each change could only keep the existing performance or make it faster. And changes that made it faster set the new watermark. Regressions required management approval.
After performance having been unimproved for a year, it was largely resolved in 6 months.
Since then I’ve been a believer that you give your developers nearly the fastest platform money can buy but then have automated, gatekeeping tests for your lowest target platform, with spot checking to make sure your tests reflect actual user experienced performance on that platform.
>management purposely prohibited developers from using really powerful machines because we needed to make the software faster.
at our BigCo these days we have a modern, dare i say Cloud Native, version of this stupidity - developers can't get even minimally powerful and reliably provisioned cloud resources (while the official rationale is similar to what you described the real one is much worse - it is just penny pinching). So it isn't just slow and unreliable, the real humongous cherry on top is that it has very short lifetime enforced by automatic deprovisioning - thus even when you finally were able to spin up our platform - which is far from guaranteed and may take many attempts as the platform is the product what we're developing, and it naturally has issues, etc. - and now you're happy and ready to start working on it, and at that moment it all disappears because of that short lifetime enforcing automated deprovisioning. Thus not surprisingly the results are exactly as you described - despite the management running around chanting cloud!cloud!cloud! our products' cloud story has so far made it practically nowhere .
at our BigCo these days we have a modern, dare i say Cloud Native, version of this stupidity - developers can't get even minimally powerful and reliably provisioned cloud resources (while the official rationale is similar to what you described the real one is much worse - it is just penny pinching). So it isn't just slow and unreliable, the real humongous cherry on top is that it has very short lifetime enforced by automatic deprovisioning - thus even when you finally were able to spin up our platform - which is far from guaranteed and may take many attempts as the platform is the product what we're developing, and it naturally has issues, etc. - and now you're happy and ready to start working on it, and at that moment it all disappears because of that short lifetime enforcing automated deprovisioning. Thus not surprisingly the results are exactly as you described - despite the management running around chanting cloud!cloud!cloud! our products' cloud story has so far made it practically nowhere .
I want a faster computer so that Visual Studio/MSVC compiles the code I write faster. I don't need a faster computer so that the application I develop runs faster. I'm already running an unoptomized debug build of our application which takes an order of magnitude of time longer to execute any given operation.
I live in a world where I cannot make performance evaluations based on my benchmarks on my "normal" build- I have to switch to a release build and recompile everything in order to make performance determinations. This led to my first personal experience of "premature optimization is the root of all evil". I implemented a new feature, performance was completely fucking untenably awful, so I threaded it. Performance was still awful, but it was 7x better because I has 7 free cores (8 total cores) to play with. I thought great, I tested, I found the bottleneck, I bandwidthed the fuuuck out the bottleneck, problem solved. A few weeks later I was testing on a release build, and in the same feature, the aforementioned bottleneck was using roughly 5% of the total CPU usage. Because the optimizer just - fixed all the slow stuff. The bottleneck that I threaded the shit out of didn't contribute significantly to the total CPU usage of the release build, while it was 87.5% or whatever of the debug build. And in the release build, I'm pretty sure all the threading overhead I added took away any and all benefit.
The thing I learned from that experience was to ignore all performance problems unless I observe them in a release build. If I had a faster computer, it would be significantly easier for me to switch back and forth between release and debug builds. And I would thus be able to observe performance problems easier.
I imagine there's a significant divide between front end web development and desktop application development here.
I live in a world where I cannot make performance evaluations based on my benchmarks on my "normal" build- I have to switch to a release build and recompile everything in order to make performance determinations. This led to my first personal experience of "premature optimization is the root of all evil". I implemented a new feature, performance was completely fucking untenably awful, so I threaded it. Performance was still awful, but it was 7x better because I has 7 free cores (8 total cores) to play with. I thought great, I tested, I found the bottleneck, I bandwidthed the fuuuck out the bottleneck, problem solved. A few weeks later I was testing on a release build, and in the same feature, the aforementioned bottleneck was using roughly 5% of the total CPU usage. Because the optimizer just - fixed all the slow stuff. The bottleneck that I threaded the shit out of didn't contribute significantly to the total CPU usage of the release build, while it was 87.5% or whatever of the debug build. And in the release build, I'm pretty sure all the threading overhead I added took away any and all benefit.
The thing I learned from that experience was to ignore all performance problems unless I observe them in a release build. If I had a faster computer, it would be significantly easier for me to switch back and forth between release and debug builds. And I would thus be able to observe performance problems easier.
I imagine there's a significant divide between front end web development and desktop application development here.
Your general point is of course correct, but “roughly 5% of total CPU usage of the release build” is absolutely worth fixing! As long as you fix it in the release build, not the debug build.
If you have a computer fast enough to do a release build quickly, it’s probably also fast enough to hide performance problems with the release build.
There are other approaches that can work, like building in the cloud so you don’t need a huge fast PC for each developer, or doing partially-optimized builds that balance build time with runtime (and debuggability).
If you have a computer fast enough to do a release build quickly, it’s probably also fast enough to hide performance problems with the release build.
There are other approaches that can work, like building in the cloud so you don’t need a huge fast PC for each developer, or doing partially-optimized builds that balance build time with runtime (and debuggability).
Why would you use the debug build though? I routinely develop using release build only and only ever execute a debug build if I really have to drop into the debugger. U find that this gives me a better experience as it puts me closer to the actual end product in terms of UX and functionality in general. (I obviously still use things like asserts that are always built in even in my release build a so I don't skip on bug detection just because it's a release build)
I was the only one using Linux (read: sub-par HW acceleration coupled with less-beefy HW) with Chrome with a user-facing web-app at a previous employer. I noticed that the UI was janky on scroll, and when I opened DevTools/Rendering/Paint Flashing I realised everything was being repainted on scroll. The culprit ultimately was a JS library deep down in the frontend that had this unintended side-behaviour. None of the UI devs ever noticed it because on their 15" MBPs on OS X everything ran "smooth enough".
> 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.
This. And if it could also throttle CPU performance, painting performance, and available cache memory to a "typical user" profile that would be ideal.
It would be best of all if that typical profile varied from day to day to cover a range of experiences of typical users, but the distribution was updated periodically from the lower quartile of the general web user population as measured by surveys.
In general: Fast developer machine for builds, slow runtime machine for using the application.
(In embedded and console games this has always been automatic :-)
If you don't run the application on a separate machine, then simulate one instead.
But there's no advantage in making IDEs, compiles and testsuites run slowly. Just the target application.
This. And if it could also throttle CPU performance, painting performance, and available cache memory to a "typical user" profile that would be ideal.
It would be best of all if that typical profile varied from day to day to cover a range of experiences of typical users, but the distribution was updated periodically from the lower quartile of the general web user population as measured by surveys.
In general: Fast developer machine for builds, slow runtime machine for using the application.
(In embedded and console games this has always been automatic :-)
If you don't run the application on a separate machine, then simulate one instead.
But there's no advantage in making IDEs, compiles and testsuites run slowly. Just the target application.
It's not a unique opinion. It also depends on your role.
I'm not quite sure how much Apple shared publicly, but there was an iOS version that caused huge performance hit for older phones (honestly, it's kind of common with new major versions, but this was an outlier). They had a .5 release that tried to improve performance. My understanding is that, like you said, developers had been developing on the newest hardware. Apple seems to be more sensitive to this and it's not because performance for phones have plateaued, but I've noticed specific regressions here and there. I remember one iPhone specifically demoed how fast the camera launched. After a few OS updates the performance was as miserable as the phones they had been mocking.
I know console developers deal with this, too. Their SDK hardware has more RAM than production hardware, but their tools generally have big flashing alarms when you exceed the memory used in production.
I'm not quite sure how much Apple shared publicly, but there was an iOS version that caused huge performance hit for older phones (honestly, it's kind of common with new major versions, but this was an outlier). They had a .5 release that tried to improve performance. My understanding is that, like you said, developers had been developing on the newest hardware. Apple seems to be more sensitive to this and it's not because performance for phones have plateaued, but I've noticed specific regressions here and there. I remember one iPhone specifically demoed how fast the camera launched. After a few OS updates the performance was as miserable as the phones they had been mocking.
I know console developers deal with this, too. Their SDK hardware has more RAM than production hardware, but their tools generally have big flashing alarms when you exceed the memory used in production.
I was around to get a peek at one of their "we need to make the OS faster and more stable" pushes and I recall engineers being told to do all their testing on the oldest, slowest iPhone still supported–everyone hated using them, of course, but when the finished product came out it was glorious how good it ran on even the oldest hardware. I get the impression that the last few releases this has been less emphasized. Performance is one way to tell this, of course, but another is that you'll notice the the UI of a lot of Apple's apps doesn't work well on smaller (and thus older) screens anymore ;)
I once had to debug an online service from a cruise ship. The network connection was painfully slow due to being over satellite. SSH is practically unusable with that latency. After suffering through that ordeal, I now take much greater care when developing software that requires internet access. Perhaps others could learn from this experience.
Yep, I had to deal with supporting an array of satnet devices and it was horrible, especially because the customers didn't understand that there was nothing we could do about clouds stopping their dashboard access...
I eventually helped design and deployed high quality LTE modems, which were awesome (with the right antennas, internet was good even in places where a phone would show no signal... but obviously the boonies on land are different than at sea!)
This is also part of the reason I am so cli/tui focused. I want to be able to run a full environment from ssh. (screen and mosh help with disconnects and instability)
I eventually helped design and deployed high quality LTE modems, which were awesome (with the right antennas, internet was good even in places where a phone would show no signal... but obviously the boonies on land are different than at sea!)
This is also part of the reason I am so cli/tui focused. I want to be able to run a full environment from ssh. (screen and mosh help with disconnects and instability)
You can enable local echo for SSH, which makes it quite usable even over latent connections.
I found mosh to be a huge improvement over standard SSH when connecting over roaming/unreliable/high latency networks.
Programmers should get whatever machine makes their build times tolerable, which probably means a pretty fast machine. Not because they are superior beings but just plain-old cost/benefit analysis.
Product managers and designers should use average equipment for their target market.
Your equipment should allow you to do your job better, not show your rank.
Product managers and designers should use average equipment for their target market.
Your equipment should allow you to do your job better, not show your rank.
Engineering labor is so valuable to companies that if getting a software engineer whatever fancy machine they want makes them some fraction of a percent more productive then it’s already a good ROI.
The other thing to consider is that when you’re hiring software engineers, your competing with everybody else who’s also trying to hire software engineers. So if a candidate sees all your engineers using a laptop that they don’t want to use, they’re likely to take that into consideration when deciding whether they want to work for you. Expensive laptops, free food/drink, a gym, free massages, and all of those other perks you might find in software companies sound extravagant, but they’re such an easy and cost effective way to compete with other employers.
The other thing to consider is that when you’re hiring software engineers, your competing with everybody else who’s also trying to hire software engineers. So if a candidate sees all your engineers using a laptop that they don’t want to use, they’re likely to take that into consideration when deciding whether they want to work for you. Expensive laptops, free food/drink, a gym, free massages, and all of those other perks you might find in software companies sound extravagant, but they’re such an easy and cost effective way to compete with other employers.
I think the “devs must have the latest hardware” meme expired probably a decade ago. Mid-range hardware is more than adequate for most devs to develop on without causing undue delays.
My work desktop is over 5 years old and still perfectly usable.
My work desktop is over 5 years old and still perfectly usable.
It's interesting, because developer tooling is subject to the very thing I mentioned too. The IDE I use the most often, Xcode, gets progressively worse to use on older hardware too because the engineers that work on it upgrade their computers to the latest as well. If your tooling has slower release cycles, your hardware can often hold out longer, but if you need to work with fast-moving tools you get to feel this pain yourself. It's really problematic because these policies have been around for quite a while now, so there are multiple levels of reasons pushing you towards the easy route of just buying faster hardware, which perpetuates the cycle even more.
Our Macs tend to be replaced in specific cycles, the same applies to the Windows laptops, regardless of what is hot in the market.
If we happen to get a customer laptop from their IT for accessing their internal network instead of some cloud instance, you can bet it is most likely fitted with 8GB and a regular HDD.
It is only on HN and Reddit bubbles that I get to see people using the very latest and greatest.
Ah, and I was part of a project a couple of years ago, where teams focused on Windows machines and literally timeshared iMacs and the respective iDevices for testing their hybrid apps.
If we happen to get a customer laptop from their IT for accessing their internal network instead of some cloud instance, you can bet it is most likely fitted with 8GB and a regular HDD.
It is only on HN and Reddit bubbles that I get to see people using the very latest and greatest.
Ah, and I was part of a project a couple of years ago, where teams focused on Windows machines and literally timeshared iMacs and the respective iDevices for testing their hybrid apps.
Developer ergonomics is worth the cost to companies. Same reason standing desks, catered meals, gym, and other amenities are offered. Why not spend an extra $1000 or so over a few years for high end hardware?
I don't disagree with the notion that a developers experience using an application might be vastly different that of a regular user and that developers might forget the fact.
Then again, even if a developer cares about performance, if it's not set as the main goal or given any resources to pursue, it will still not get the much deserved attention.
Performance on lower grade consumer devices should absolutely be a minimum pass criterions, but if it isn't, giving developers older devices will not help.
Then again, even if a developer cares about performance, if it's not set as the main goal or given any resources to pursue, it will still not get the much deserved attention.
Performance on lower grade consumer devices should absolutely be a minimum pass criterions, but if it isn't, giving developers older devices will not help.
I think it's important to have both (and indeed, do use both): a blazing-fast development machine for actually writing the code and a slow-as-molasses test machine (be it separate hardware or a heavily-handicapped VM on the fast machine) for dogfooding/testing the code. With the former, the faster the better; with the latter, the slower the better.
> I think the assumption that a company should outfit their developers with “the best” machines is problematic.
I’ve worked at several production companies, games & films, that had policies of giving devs the worst machines. The thinking being that artists who use the tools should always feel less pain than the devs who make the tools, not more.
I’ve worked at several production companies, games & films, that had policies of giving devs the worst machines. The thinking being that artists who use the tools should always feel less pain than the devs who make the tools, not more.
In fairness the artists were probably editing and rendering assets that also required them to have very high spec machines too.
I half agree with you, that's why I always hesitated before upgrading to a new phone. A good approach is to explicitly encourage testing and require good performance on average hardware. There are many possible policies that help to achieve this goal, but forcing devs to develop on average hardware is too extreme.
Great point, but it's probably worth it if it accelerates development time, even by a little - or - makes devs. feel that their cool and that they are working at a 'good company'.
Not sure what that dollar figure looks like though.
I'm writing this on a 2011 Mac. Well maintained.
Not sure what that dollar figure looks like though.
I'm writing this on a 2011 Mac. Well maintained.
I disagree on many levels. I firmly think (being both a developer and a project lead) that the developers which build an application, should have the beefiest and fastest machine that money can buy. Especially if you want to have a fast product. Why is this?
- First of all, faster hardware means better productivity. If you want the developers have time to optimize for speed, better give them the time for this. Cutting their productivity usually means, less time is spend on optimizing, all "features" need to be implemented first. Only when all "features" have been implemented, quality improvements get scheduled. You want developers to be productive enough that they get time to improve quality/speed.
- Developers are running the application completely differently than the end users. If an application is run for hours if not even days at a time, startup speed doesn't count much. A developer might have to restart an application for debugging something every minute[1]. Having the developer waiting on startup would be a bad waste of time. While it might be nice to optimize startup times, the really might not be customer-relevant.
- Developers often run unoptimized code with debug code present or even inside a debugger. This makes the code often slower than the customer experience.
- Developers might have to run several instances of the application at the same time, requiring the neccessary compute resources, also the development environments need to be powered.
- And to some extend, which gets revived by the power of these new chips, development often happens years before a product ships. What is an exotic and expensive machine at the project start, might be a medium range for the customer when the product ships. So the development machine was actually a good match of the deployment platform.
These are some of the reasons why developers should have powerful machines. Of course, there are also a lot of reasons to test the product on less powerful machines and set performance goals according to these tests. But this doesn't mean the developer has to do the development work on those machines. If a product doesn't get tested enough and on the right systems, it is rather a project management issue.
1: I am fortunate to do quite a bit of my work in Lisp and it is one huge productivity boost that I can update every single function redefinition in the running code. Which gives me increadibly short iteration cycles. The cost of starting up an application to test a change isn't just the startup time but also the interaction needed until you get to the point where the function is called, I am doing quite UI-centric work. This becomes very noticable, whenever I actually have to restart the application to get a meaningful test. Even worse are the situations where I even have to wait for a longer compilation run (with non-Lisp languages, like C++)
- First of all, faster hardware means better productivity. If you want the developers have time to optimize for speed, better give them the time for this. Cutting their productivity usually means, less time is spend on optimizing, all "features" need to be implemented first. Only when all "features" have been implemented, quality improvements get scheduled. You want developers to be productive enough that they get time to improve quality/speed.
- Developers are running the application completely differently than the end users. If an application is run for hours if not even days at a time, startup speed doesn't count much. A developer might have to restart an application for debugging something every minute[1]. Having the developer waiting on startup would be a bad waste of time. While it might be nice to optimize startup times, the really might not be customer-relevant.
- Developers often run unoptimized code with debug code present or even inside a debugger. This makes the code often slower than the customer experience.
- Developers might have to run several instances of the application at the same time, requiring the neccessary compute resources, also the development environments need to be powered.
- And to some extend, which gets revived by the power of these new chips, development often happens years before a product ships. What is an exotic and expensive machine at the project start, might be a medium range for the customer when the product ships. So the development machine was actually a good match of the deployment platform.
These are some of the reasons why developers should have powerful machines. Of course, there are also a lot of reasons to test the product on less powerful machines and set performance goals according to these tests. But this doesn't mean the developer has to do the development work on those machines. If a product doesn't get tested enough and on the right systems, it is rather a project management issue.
1: I am fortunate to do quite a bit of my work in Lisp and it is one huge productivity boost that I can update every single function redefinition in the running code. Which gives me increadibly short iteration cycles. The cost of starting up an application to test a change isn't just the startup time but also the interaction needed until you get to the point where the function is called, I am doing quite UI-centric work. This becomes very noticable, whenever I actually have to restart the application to get a meaningful test. Even worse are the situations where I even have to wait for a longer compilation run (with non-Lisp languages, like C++)
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.
> 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.
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.
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.
Office, Excel, Figma, 5 other web-apps, Slack, 30+ websites, Spotify - no problem.
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
Depends on the usecase but we find Chrome to be significantly faster than Firefox in JS performance.
>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)
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)
This seems like a case of the Jevons Paradox, where the "resource" is CPU cycles: https://en.wikipedia.org/wiki/Jevons_paradox
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?
Parkinson's law https://en.wikipedia.org/wiki/Parkinson%27s_law
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?
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?
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.
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.
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.
So technically I'm not sure how much you can abstract away for performance.
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”.
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.
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.
Being able to use complex things makes you look smart.
Creating a complex system makes you look even smarter.
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.
Ideally (IMO), if you want to optimize development time, also consider future development time.
Technical debt means guaranteed work in the future for software developers.
I only say this half-jokingly.
I only say this half-jokingly.
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.
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.
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?
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.
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).
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).
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.
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.
> 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.
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.
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.
Sure, in all the bloat there's new functionality, some of it even useful. But if you just take a simple, well defined task, like starting a program and loading an appropriate file (any photo editor, Excel, Word...), I would expect it to load instantly.
If our hardware has sped up 1000x, couldn't the software limit itself to slowing things down only 500x instead of 2000x?
If our hardware has sped up 1000x, couldn't the software limit itself to slowing things down only 500x instead of 2000x?
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.
> 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.
Yet another post blaming developers when it's the product managers and business development people that decide the direction of the product.
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.
> Yet another post blaming developers when it's the product managers and business development people that decide the direction of the product.
Developers on this very site will happily deliver a slow running JS Electron turd if that means that they don't have to learn a new tool or use the process that isn't "fun" to them. Blaming just the business owners when the developers themselves refuse to do their job well is a bit strange.
Kinda reminds me of life in my socialist state - everyone did their minimum to tick the box they had to do and then just slacked off the rest of the time. Everything was kinda shit but it's not like anyone got paid more to do a job well, amirite?
Developers on this very site will happily deliver a slow running JS Electron turd if that means that they don't have to learn a new tool or use the process that isn't "fun" to them. Blaming just the business owners when the developers themselves refuse to do their job well is a bit strange.
Kinda reminds me of life in my socialist state - everyone did their minimum to tick the box they had to do and then just slacked off the rest of the time. Everything was kinda shit but it's not like anyone got paid more to do a job well, amirite?
Oh? Then can you explain why the same phenomenon happens in FOSS software?
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.
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.
"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!"
"But that's not fun and I don't have time, need to hack the new one!"
> 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.
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.
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.
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.
> 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...
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...
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.
"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.
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.
That was the moment, I realized that we are doing something wrong today and that performance should always be evaluated.
> 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.
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.
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.
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.
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.
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.
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.
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.
If I remember correctly, Metal predates Vulkan, so the argument could be vice versa :)
> 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.
> 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.
> 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.
This is actually the WebKit project's policy. Performance regressions are not allowed and you can't commit any without adding an equivalent progression.
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
[2] https://hn.algolia.com/?q=https%3A%2F%2Ffabiensanglard.net%2...
[1] https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law
[2] https://hn.algolia.com/?q=https%3A%2F%2Ffabiensanglard.net%2...
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.
> 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.
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.
“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
To save dev time, people are no longer building native. And that bloat keeps adding up, masquerading as abstraction
It's a pretty straightforward law of physics: software is a gas that expands to fill its container.
The SuperHuman webmail client claims to have a 100ms rule. 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.
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.
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).
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).
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.
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.
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.
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.
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.
"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.
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.
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?
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?
> 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.
[deleted]
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.
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.
For productivity apps I could see this working, but this would be the death of e.g. phone games, VR experiences etc.
Some things just take a lot of power to compute.
The issue I see is that it's kind of hard to measure whether the app needs this much CPU or if it's a bad design.
Aligning these incentives is obviously necessary. But it's not such an easy problem.
You'd have to start categorizing apps by how fast they should be (e.g. calendars should start in < 0.5 seconds and use at most 3% CPU on average). Then you may be able to align incentives this way. However then the problem becomes categorizing your apps and having useful categories for everything. Then maybe somebody has an idea for an AI calendar that needs more CPU, but is a lot more useful, because it can predict a host of events. Now they can't upload that to the app store.
Some things just take a lot of power to compute.
The issue I see is that it's kind of hard to measure whether the app needs this much CPU or if it's a bad design.
Aligning these incentives is obviously necessary. But it's not such an easy problem.
You'd have to start categorizing apps by how fast they should be (e.g. calendars should start in < 0.5 seconds and use at most 3% CPU on average). Then you may be able to align incentives this way. However then the problem becomes categorizing your apps and having useful categories for everything. Then maybe somebody has an idea for an AI calendar that needs more CPU, but is a lot more useful, because it can predict a host of events. Now they can't upload that to the app store.
I wonder if Apple could reduce the regulatory pressure on them by charging App Store fees as a function of bandwidth usage that Apple must use to serve the app. This would incentivize developers to keep their app bundles small ;)
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.’
Google definitely uses pagespeed as a major factor. They may also with AMP although that may be changing. They could do more though.
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.
Why would Apple want this? Slow stuff makes you upgrade to the new thing.
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.
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
[2] https://www.imore.com/debug-111-don-melton-blink-servo-and-m...
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
[2] https://www.imore.com/debug-111-don-melton-blink-servo-and-m...
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.
I think firefox is again faster and leaner compare to chrome.
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.
Is there a Wordpress theme that will make my website look like OP's?
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.
Chase is the worst. So slow I've missed credit card payments over it.
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.
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.
Thank you.
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.
If it was 32GB I’d buy.
But a fast CPU is only marginally useful when my machine grinds from memory swapping.
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.