10 ms·

Performance Matters (2019)

153 points by azhenley 6y ago

pjkundert 6y ago
Software can be bad in arbitrary way, and still be useful and not too agonizing. But, software that ignores, delays or discards user inputs? Absolutely F*$#ing Unacceptable. Unfortunately, most user-interface software (including the ePCR software described in this article) commits this "Unpardonable Sin" of UI software. So, the EMTs, being insulted by the software developer, just don't use it. If you write UI software, you have one job. To utterly cherish user input, painstakingly preserve it, and lovingly and promptly provide user output. That's it. Almost anything else is optional, and can be forgiven.
- austincheney 6y ago
  As a front-end developer my professional experience tells me that in practice the ONLY (cannot stress this enough) thing that matters is developer convenience in the code. Everything else be damned. That said if this UI failure was easier for the developers to code, such as no code and download from NPM, then it is most correct even if both the business and end user are both catastrophically harmed immediately.
  - 8ytecoder 6y ago
    There were solid good practices from the way back when Struts was a thing. Even when a server side validation fails, you can redirect the user to a page and the form can prefill the inputs (except password). This was across page refreshes. What happened to all those hard learned lessons?
    - sriku 6y ago
      These days you don't even get that on most occasions even in a "forgot password" flow. You still have you key in your email address or username again pretty much everywhere.
  - saagarjha 6y ago
    This heavily depends on field, I believe.
- ajnin 6y ago
  Unfortunately Firefox is guilty of that Unpardonable Sin. Often I will open a new window to search for something and start typing my request right away, since the address/search bar should be focused on new windows. If the window takes a little bit of time to appear for some reason, the first few characters will be dropped. Frustrating. Chrome on the other hand does not exhibit this defect, even if I start typing before the window actually appears, my input is preserved.
  - kzrdude 6y ago
    MS Teams. Be in a call with a person and write something long in the chat message box, without sending it yet. This disappears when the call ends, even if it could just be transfered to the message box in the chat view with that person.
  - throwaway_pdp09 6y ago
    So it does. Not if you open a new tab, but for a new window (just tried it on palemoon, an FX fork). As I never open a new window, never hit it. Do a bug report I suggest.
  - ALittleLight 6y ago
    I find the autocomplete in jira constantly doing absolutely preposterous things - e.g. I'll be typing out a query like "project != TheirProject" and, when I've finished typing "TheirProject" and hit enter, jira has just barely managed to raise an autocomplete prompt such that "TheirProject", which is correctly spelled, gets "autocompleted" to something like "!=" making my entire query "project != !=". I have no idea what's happening in this case as autocomplete seems to take a completed correct term and turn it to something that isn't even semantically valid. It happens to me in some variety at least once a day.
  - TeMPOraL 6y ago
    Firefox has too many abstraction layers. The other day I've managed to break the multi-account containers, because I pressed Enter (to confirm opening a site in a different container) faster than the confirmation page finished loading, which yielded a) an empty tab with no site, and b) a confirmation page with no URL in it, that did nothing. Software should never break because flesh-and-bone human user is "too fast" for it.
- greggman3 6y ago
  Almost all software that has a login seems to throw away input. It's at the "forgot my password" prompt. I type in my email to login. I type a password. It doesn't work. I click "forgot my password" and I have to type my email again. On desktop it's not too annoying but on mobile I find it super frustrating.
- johnisgood 6y ago
  Make animation optional at least! Just clicking into an input field can cause a system hangup.
momokoko 6y ago
I think this is missing the point. Did they ask the people who would actually use the software if they would use the software? All the way from design to implementation to the team that purchased the software. This is what happens when no one checks with the person that will actually use the software everyday. You end up with checked boxes and wasted resources.
unnouinceput 6y ago
Of course performance always matter. Also testing your software under real usability also helps understand the performance. Story time: I got hit by performance these very days. The app I'm developing for one of my clients has to process images from an USB camera. Under my development everything is dandy. Works like a charm, images gets processed and when the user hits the on-screen button that image gets stored in database as part of the entire process. Neath, yeah? Well, it turns out my client is using a cheap from last decade tablet (I'm a purist so this decade will end on 31st Dec 2020) that due to processing 30 frames each second from USB camera, has little time for actual GUI responsiveness. And the app feels sluggish, with 1 second delay between my tap and the combobox firing up. Turns out, it didn't need to actually process all those 30 frames each second. On per second will suffice, hence I've implemented to only process on frame every second. More than enough for customer's needs and now the app is also flying on that old hardware. My 2 cents.
- Const-me 6y ago
  > hence I've implemented to only process on frame every second That's merely a workaround, not a fix. Next day someone will use a 8k camera on the same slow tablet. Another day someone will run your app in parallel with with some other process consuming all CPU cores. A fix would be making so that however slow the computer is, processing frames from the camera doesn't affect GUI latency, at least not by much. You probably gonna need multithreading for that. And if that 2010 tablet only has a single CPU core without hyperthreading, you might need to adjust the priority of that camera's thread. But it's all doable.
  - unnouinceput 6y ago
    I have bad news for you my friend. Everything is a workaround. You do workaround your family, you do workaround your kids and you do workaround your health. You have seat-belts on your car? Is that a fix or a workaround? Because a fix would be to actually have a car that doesn't crash at all. But would not be economically viable. You have plastic insulator around your electricity wires to prevent you getting electric shock. Is that a fix or a workaround? Because a fix would be to actually have continuous current at max 12V as power lines. But that's not economically viable. You have kids going to school and strangers are educating your kids a good portion of their life, molding them sometime against your values. Is that a fix or a workaround? Because a fix would be to have them home-schooled under your eye. But that's not economically viable. I can do this all day.
liquidify 6y ago
In my limited software engineering experience, most things are slow because they are built on other things that are slow. Generally people do not build software from the ground up. They simply reuse endlessly until someone high up gets so frustrated that they demand a complete rebuild. Then we start over by downloading a bunch of libraries and the same process begins again.
- sim_card_map 6y ago
  Or because we created languages like Python that are 10x slower than compiled languages and write code bases with millions of lines of code in them.
  - hansvm 6y ago
    It's 10x slower at a lot of things, but even vanilla cpython is every bit as compiled as something like C#. Python is slow because of an extraordinary amount of runtime dynamism, because it doesn't have a JIT or many optimization passes, and because performance isn't a top concern of the project.
    - charliebreslau 6y ago
      Higher abstraction -> less bugs. Forget low level, I beg you.
  - oddity 6y ago
    I'm not sure this is a useful summary of the problem. I've seen an awful lot of code written in C and C++ that pisses away any and all advantage of using either. In general, I think software devs (and the software market) tend to value convenience over performance until it's too late, but the reasons why are so complicated and different per sector they'd make for a full PhD thesis and then some.
  - rubatuga 6y ago
    PyPy is actually very fast, ~10x faster than standard python.
kuharich 6y ago
Past comments: https://news.ycombinator.com/item?id=20718315 https://news.ycombinator.com/item?id=20718315
- JshWright 6y ago
  Oh man, 2020 has been a long year... I totally forgot this had been posted before and I managed to repeat myself in the comments...
outworlder 6y ago
This matters more than one would think. I've once worked on a system that was objectively slow. Some actions would take seconds to complete. It's not like people would refuse the use the system, it was the only way to do their jobs. The public had no choice, either. Initially, I didn't think it was such a big deal. Yes it was a bit slow, but nothing _terrible_ and why did it matter, since there were so many other procedures that took way longer than the software step. It was a government facility, lots of red tape. Surely optimizing some of the paper processes would be more beneficial. But we optimized it anyway. Not because the UI was slow(which we didn't even measure directly), but because it was slow for a reason - backend processes were taking time, and resources. If we could optimize, we thought, we would save resources (and also increase the runway until we had to expand again, buy hardware and the like). First round of optimization was completed. Lots of low hanging fruits(many database-related). Testing indicated that the backend would be faster by almost an order of magnitude. Deployed. THE SYSTEM BECAME SLOWER. How was that possible? Maybe we had missed something. We found more bottlenecks, optimized those. Deployed again. Everything is slow again. What's happening?! We went to the 'field' - as in, talked to the users. Well, this is what we discovered: we saw the backend working harder - because the users were more productive! Instead of staying after the facilities were closed to the public and then catching up on whatever paperwork they were unable to enter in the system, they could process everything almost as fast as people came in. Which means that they could go home early. What we saw as "the system being slow again" was due to bad metrics - we were watching backend load, not UI response times. Because, admittedly, that didn't bother us directly. Not until we talked to the poor souls that had to use the system. Lots of async processes got triggered and queues filled up, but it didn't really matter to the users, as long as the UI said things were submitted and they could move on. After that, we optimized the heck out of all the UI interactions we could find.
- eyelidlessness 6y ago
  This is great for two reasons (and probably more): 1. It highlights that user impact determines success more than resource metrics. 2. It shows that assumptions infect even when you think you’ve accounted for assumptions. Honorable mention: don’t just prove the abstraction and call it done. It’s got to prove itself in real world scenarios before you can trust its claims!
joe_the_user 6y ago
I'd just mention another scenario where performance matters more than is imagined. It's common for people to reference Rich Sutton's The Bitter Lesson Of Machine Learning [1], which essentially says that brute force has always beaten "clever algorithms". I'd outline an alternative view to this. The development of "clever algorithms" in the GFAI days or pre-neural-nets computer visions days often didn't follow an approach where the different parts could be combined together in a fashion that was performant. It seems like the higher you go in CS theory, the more speed gets abstracted away. And the problems with that might be the real lesson here. [1] http://www.incompleteideas.net/IncIdeas/BitterLesson.html http://www.incompleteideas.net/IncIdeas/BitterLesson.html
obviouslynotme 6y ago
I'm old enough to remember Win32 programming in C/C++ because it was the only thing that worked. There was a problem though. Memory management, shitty standard library, and a non-existent packaging system. Java came around and gave you something that worked. Memory management? The runtime does it. Want to do X? Here is a library for X. These combined with academia moving over to Java killed new C++ development hard. It seemed good at the time. Java sucked but Widgets and MFC sucked harder. Qt wasn't that popular yet. There was only one problem with Java. Even on new machines, you would get noticeable random pauses doing simple things. This never happened in C++ apps even with full MFC bloat. The GC just wasn't that good yet. Programmers would also include FAR more code and libraries because it sped development up. Even today, C++ applications only include libraries if they absolutely have to because of how painful it is. All of C++'s disadvantages become advantages when you look at them from the lens of performance. Manual memory management means that even if you are slow, you are consistently slow. You don't get the peaks and valleys that really irritate humans who are incredibly sensitive to rhythm. Memory leaks are honestly not even a problem unless you have long running servers. Even then, you could honestly just restart. The near-complete lack of standard libraries and complete lack of a package system highly reduced the amount of fluff you had. If you wanted it in your software, you had to do it yourself. This led to very simple, non-pretty, static interface that just tried to look like Word without the Toolbar of Death. The best optimization has always been to Do Less Stuff. It's only going to get worse too. The same companies who think C++ is too complex for their programmers are going to laugh at Rust. People in Java or .NET shops aren't going to move over. "Native" is increasingly becoming a JavaScript space which has all the terrible performance of JavaScript usually combined with the slowness of internet connections. For good and ill, package management is now standard. Microsoft Office used to run fast on a 486 with megabytes of ram. Think about that. Are you a more complex or intensive program than Word? I bet that ePCR has far higher specs. The program running on it isn't inherently more complex. It's literally a form filler, but it isn't used because of how ridiculously bloated even the most basic software has become. In the 90's, you could have made that machine by installing Windows on a machine and programming a VB program in a few weeks that hooked up to a printer. It would have been more responsive than a state-of-the-art ePCR that sits unused today.
- hansvm 6y ago
victorronin 6y ago
What would happen if you replace "performance" in this article with "not contrast enough UI" or "bad autocorrect" or "annoying background music"? Should this article have been "Good autocorrect matters"? The problem here isn't performance. The problem here is that the company which is building this software are so remote from end-user that they don't hear feedback. If they knew that performance is the problem and multidollar contract with some huge network of hospitals were at risk, I can bet you, this performance issues would have been fixed really fast.
- eyelidlessness 6y ago
  It isn’t as simple as that but I still want to recognize and applaud this response. You’re right, performance isn’t the fundamental issue, distance from user need and user pain is. Unfortunately even where that distance is short, mitigation can be hard to achieve. Understaffed and underfunded orgs can be wildly aware and even obsessed with shortcomings in their offerings and still fail to deliver improvements. I’ve worked in such orgs, I’ve seen overworked, deeply caring and empathetic and dedicated engineers trying to move mountains to fix (and have habitually been one myself). More to the point: unfortunately the software needs in the world, and the ways the world are underserved by software, are competing for resources and organizing talent with organizations that fundamentally don’t serve those needs. And both categories are competing in a limited pool, because software’s capabilities have outpaced the available talent to take advantage of those capabilities. Good for my bank account, I guess. But bad for people and the world we (I) inhabit. And bad for me too, probably even more than I know. Anyway this is far afield of parent comment’s point, but I felt it was a good place to add a little depth as an engineer who gives a damn but rarely sees the opportunity to apply damns.
  - xupybd 6y ago
    I can't agree more. Everyone wants amazing software yesterday. They don't want to spend money to do it. The company that wins the bid tends to over promise on delivery dates and under supply resources to do it.
- greggman3 6y ago
eyelidlessness 6y ago
One thing I don’t see mentioned here (haven’t looked at the past comments link but it’s worth surfacing here) is that requirements for many public RFPs, health care being right up there, is that since most people driving the process aren’t intimately familiar with software success and failure cases tend to refer to the intersection of tech and regulation. They don’t necessarily think about usability except in terms of a11y. Uptime, yes. Human experience interacting with it? Likely only if it resembles workflows that are similar and painful for them. This isn’t faulting these people defining these requirements! It’s a call to all the types of HN readership to put yourself more in the position to bring the knowledge that informs your contribution into the requirements process. You might never know that the success of the project you work on depends on your knowledge of color accuracy or time zones or particular patterns of abuse... until you get yourself a seat at the “first things first” table.
JshWright 6y ago
"If 0.1% of PCRs have mistakes that waste an hour of a doctor’s time, that’s 30,000 doctor-hours not spent on other patients." There is a 0.0% chance that this happens (in my opinion as a paramedic). If I had to guess, 0.1% is probably the rough order of magnitude of the frequency with which doctors look at the PCR at all. We give a verbal report which covers the important details. I would be hard-pressed to come up with an error that could possibly waste an hour of someone's time. "Did that quarter-second lag kill anyone? Was there someone who wouldn’t have died if the ePCR was just a little bit faster, fast enough to be usable? ... It could have saved the person the EMTs couldn’t get to because they lose an hour a week from extra PCR overhead." Similarly, no. There is no situation in EMS where 250ms is the difference between life and death. It's not like the tones drop for a call and we say 'gee, I wish I could go help that person, but I still have this chart to write...'. Performance absolutely matters (ironically, I'm a software developer for an EMR at my day job), but a little lag in an ePCR isn't going to kill anyone.
- hxtk 6y ago
  > There is no situation in EMS where 250ms is the difference between life and death. It's not like the tones drop for a call and we say 'gee, I wish I could go help that person, but I still have this chart to write...'. That wasn't how I read it. I may be incorrect, but my interpretation was that the 250ms didn't make the software too slow to be effective but rather too slow to be user friendly. The idea isn't that it directly killed people by being slow, but rather that it was not adopted because people didn't like using it, and on the paper alternative, mistakes were made that would have been impossible to make on the computer.
  - JshWright 6y ago
    I don't have a choice about whether I use an ePCR or not, New York State (and, AFAIK, most other states) mandates it. The only place where PCR errors matter is on the witness stand... The PCR is certainly important, but any critical information is conveyed in a number of redundant ways, and I would be very surprised if there's been a single incidence of a PCR error resulting in a patient's death. PCRs are not treated with a great deal of trust, nor should they be (I say this as someone who has written thousands of them). We're dealing with incomplete and conflicting information, patients that actively lie (or, more charitably, forget) about their medical history, and in the case of critically sick patients (the ones that are at risk of dying in the first place) I am more focused on the acute management of their condition. No one expects a PCR to be accurate in every detail. That doesn't mean it's useless, but it also means the system expects there to be errors and has redundancies in place to account for that.
brundolf 6y ago
> But this isn’t “critical software”, either I strongly disagree. Anyone on the project would have (hopefully) known what it was being used for and how critical timing is for that task. Heck, the entire reason the project exists is to expedite the task. That translates directly to minimum-latency being a project constraint, so this to me just sounds like a project that failed to meet its constraints. If you're an application developer, you're generally going to have a clear idea of what the priorities are for your project and what does and doesn't matter (in terms of performance and otherwise). Maybe there's a case here for systems/library programmers erring on the side of performance because they genuinely don't know who will be using their code for what. But even then- if a library isn't fast enough (put differently: if the library's priorities diverge from the application's priorities), the application developer should know that and not use that library for their application. This trend of universalist performance-puritanism is exhausting. Performance is one of many priorities that a project may have. Know your target user, set your priorities accordingly, and develop your code in line with those priorities. No single priority gets to be so important across an entire field that everything else takes a back-seat.
jmnicolas 6y ago
I remember a comment here about a similar discussion about performances. The author made such a good praise of performance that I was half ready to learn ASM to code all my apps ... then he admitted he was using this Electron app because it was more featurefull than the native one ...
luckystarr 6y ago
I worry most people don't get the point of the Knuth's quote "Premature optimization is the root of all evil". Here is the full quote: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." What most people do is ALSO pass up optimizing that critical 3%, so software gets slower and slower. What he (probably) really meant is: "don't micro-optimize what a compiler can do better, optimize your algorithms and data-structures" Some common excuses for bad code: - Shuffling data around needlessly? Not a problem. It's fast enough. - The algorithm is bad. Not a problem. It's fast enough. - This is obviously bad. Not a problem. It already takes minutes, so a few more won't matter. - The code is slow. Not a problem. It's only used internally.
VBprogrammer 6y ago
I've recently been knees deep in optimising some old python multi processing code. I threw everything at it from trying to optimise the SQL queries it made to pre-fetching multiple requests to its child processes. In the end I broke out pyinstrument and found some logging in a loop which was taking up a big chunk of parent time. Fixing that gave a 2x performance increase. I went back and tested the various changes I'd made to that point and thankfully found that most of them were needed to sustain that performance improvement but it was a good reminder to break out the profiler first, not last.
noisy_boy 6y ago
> It wasn’t even that slow. Something like a quarter-second lag when you opened a dropdown or clicked a button. But it made things so unpleasant that nobody wanted to touch it. Considering the no. of fields on that form, with that kind of lag, I'll be ditching it too. I mean most of it is check-boxes; just replicate the damn thing on html. Though without knowing more about the setup, I would guess that hardware with terrible input is also involved.
MaxBarraclough 6y ago
A slight nitpick: > The ambulance I shadowed had an ePCR. Nobody used it. I talked to the EMTs about this, and they said nobody they knew used it either. Lack of training? No, we all got trained. Crippling bugs? No, it worked fine. Paper was good enough? No, the ePCR was much better than paper PCRs in almost every way. It just had one problem: it was too slow. That is a crippling bug. The UI is a soft real-time system, [0] and it's doing such a poor job of meeting its deadlines that the user considers the system to be unusable. If you're writing an autopilot system, it's not enough for the system to eventually make the right decision, it must arrive at the right decision before the deadline. Failure to do so would by definition qualify as a bug. > Most of us aren’t writing critical software. But this isn’t critical software, either: nobody will suddenly die if it breaks. Won't they? If the software corrupts the patient data, someone could die, right? Elsewhere the article essentially says as much: > An error might waste valuable time as nurses chase invisible problems or ignore obvious ones. Worst case, it leads to the wrong treatment. In emergency situations these mistakes can be fatal. [0] https://en.wikipedia.org/wiki/Real-time_computing#Soft https://en.wikipedia.org/wiki/Real-time_computing#Soft edit I see brundolf's comment already makes some of these points
- jspash 6y ago
  I would argue that the 250ms lag mentioned in the article was not the reason the ePCR system was perceived as being slow. Consider the new trend in login forms these days whereby you are forced to enter you username or email THEN press a button THEN enter your password THEN press another button. What used to be simple is now no longer simple. Why is it like this? To accommodate the x% of people who seem to get confused in some manner when presented with "too many choices". I forget the reasoning now, and disagree 1000% but don't want to sidetrack my argument any further. Anyhow... compare the original form to an imagined GUI since we're not presented with the software to make a proper comparison. If you needed to fill out the paper form quickly you can tick..tick...tick..tick..write a bit.tick...tick..read..write.etc. Now with the software, does it use a mouse? Probably not. It's most likely a touch screen. Possibly a tablet. So now every choice required more interaction. More choices. Opening a dropdown? So you mean to say the developers have decided to hide important information until you request it? The paper version has everything you ever need to know at a glance. One side of a sheet, no need to even flip it over. This is all conjecture, but I experience this type of thing all the time when a software "solution" comes to fix a real-world "problem". It can be done well. Most UK Govt websites are incredibly well-done IMHO. But usually they're not.
legulere 6y ago
For a reference, this is how fast you should be: - animations under 10 ms - reacting to user interactions under 50ms https://web.dev/rail/#focus-on-the-user https://web.dev/rail/#focus-on-the-user

153 points by azhenley 6y ago

Software can be bad in arbitrary way, and still be useful and not too agonizing. But, software that ignores, delays or discards user inputs? Absolutely F*$#ing Unacceptable. Unfortunately, most user-interface software (including the ePCR software described in this article) commits this "Unpardonable Sin" of UI software. So, the EMTs, being insulted by the software developer, just don't use it. If you write UI software, you have one job. To utterly cherish user input, painstakingly preserve it, and lovingly and promptly provide user output. That's it. Almost anything else is optional, and can be forgiven.

austincheney 6y ago
As a front-end developer my professional experience tells me that in practice the ONLY (cannot stress this enough) thing that matters is developer convenience in the code. Everything else be damned. That said if this UI failure was easier for the developers to code, such as no code and download from NPM, then it is most correct even if both the business and end user are both catastrophically harmed immediately.
- 8ytecoder 6y ago
  There were solid good practices from the way back when Struts was a thing. Even when a server side validation fails, you can redirect the user to a page and the form can prefill the inputs (except password). This was across page refreshes. What happened to all those hard learned lessons?
  - sriku 6y ago
    These days you don't even get that on most occasions even in a "forgot password" flow. You still have you key in your email address or username again pretty much everywhere.
- saagarjha 6y ago
  This heavily depends on field, I believe.
ajnin 6y ago
Unfortunately Firefox is guilty of that Unpardonable Sin. Often I will open a new window to search for something and start typing my request right away, since the address/search bar should be focused on new windows. If the window takes a little bit of time to appear for some reason, the first few characters will be dropped. Frustrating. Chrome on the other hand does not exhibit this defect, even if I start typing before the window actually appears, my input is preserved.
- kzrdude 6y ago
  MS Teams. Be in a call with a person and write something long in the chat message box, without sending it yet. This disappears when the call ends, even if it could just be transfered to the message box in the chat view with that person.
- throwaway_pdp09 6y ago
  So it does. Not if you open a new tab, but for a new window (just tried it on palemoon, an FX fork). As I never open a new window, never hit it. Do a bug report I suggest.
- ALittleLight 6y ago
  I find the autocomplete in jira constantly doing absolutely preposterous things - e.g. I'll be typing out a query like "project != TheirProject" and, when I've finished typing "TheirProject" and hit enter, jira has just barely managed to raise an autocomplete prompt such that "TheirProject", which is correctly spelled, gets "autocompleted" to something like "!=" making my entire query "project != !=". I have no idea what's happening in this case as autocomplete seems to take a completed correct term and turn it to something that isn't even semantically valid. It happens to me in some variety at least once a day.
- TeMPOraL 6y ago
  Firefox has too many abstraction layers. The other day I've managed to break the multi-account containers, because I pressed Enter (to confirm opening a site in a different container) faster than the confirmation page finished loading, which yielded a) an empty tab with no site, and b) a confirmation page with no URL in it, that did nothing. Software should never break because flesh-and-bone human user is "too fast" for it.
greggman3 6y ago
Almost all software that has a login seems to throw away input. It's at the "forgot my password" prompt. I type in my email to login. I type a password. It doesn't work. I click "forgot my password" and I have to type my email again. On desktop it's not too annoying but on mobile I find it super frustrating.
johnisgood 6y ago
Make animation optional at least! Just clicking into an input field can cause a system hangup.

momokoko 6y ago

I think this is missing the point. Did they ask the people who would actually use the software if they would use the software? All the way from design to implementation to the team that purchased the software. This is what happens when no one checks with the person that will actually use the software everyday. You end up with checked boxes and wasted resources.

unnouinceput 6y ago

Of course performance always matter. Also testing your software under real usability also helps understand the performance. Story time: I got hit by performance these very days. The app I'm developing for one of my clients has to process images from an USB camera. Under my development everything is dandy. Works like a charm, images gets processed and when the user hits the on-screen button that image gets stored in database as part of the entire process. Neath, yeah? Well, it turns out my client is using a cheap from last decade tablet (I'm a purist so this decade will end on 31st Dec 2020) that due to processing 30 frames each second from USB camera, has little time for actual GUI responsiveness. And the app feels sluggish, with 1 second delay between my tap and the combobox firing up. Turns out, it didn't need to actually process all those 30 frames each second. On per second will suffice, hence I've implemented to only process on frame every second. More than enough for customer's needs and now the app is also flying on that old hardware. My 2 cents.

Const-me 6y ago
> hence I've implemented to only process on frame every second That's merely a workaround, not a fix. Next day someone will use a 8k camera on the same slow tablet. Another day someone will run your app in parallel with with some other process consuming all CPU cores. A fix would be making so that however slow the computer is, processing frames from the camera doesn't affect GUI latency, at least not by much. You probably gonna need multithreading for that. And if that 2010 tablet only has a single CPU core without hyperthreading, you might need to adjust the priority of that camera's thread. But it's all doable.
- unnouinceput 6y ago
  I have bad news for you my friend. Everything is a workaround. You do workaround your family, you do workaround your kids and you do workaround your health. You have seat-belts on your car? Is that a fix or a workaround? Because a fix would be to actually have a car that doesn't crash at all. But would not be economically viable. You have plastic insulator around your electricity wires to prevent you getting electric shock. Is that a fix or a workaround? Because a fix would be to actually have continuous current at max 12V as power lines. But that's not economically viable. You have kids going to school and strangers are educating your kids a good portion of their life, molding them sometime against your values. Is that a fix or a workaround? Because a fix would be to have them home-schooled under your eye. But that's not economically viable. I can do this all day.

liquidify 6y ago

In my limited software engineering experience, most things are slow because they are built on other things that are slow. Generally people do not build software from the ground up. They simply reuse endlessly until someone high up gets so frustrated that they demand a complete rebuild. Then we start over by downloading a bunch of libraries and the same process begins again.

sim_card_map 6y ago
Or because we created languages like Python that are 10x slower than compiled languages and write code bases with millions of lines of code in them.
- hansvm 6y ago
  It's 10x slower at a lot of things, but even vanilla cpython is every bit as compiled as something like C#. Python is slow because of an extraordinary amount of runtime dynamism, because it doesn't have a JIT or many optimization passes, and because performance isn't a top concern of the project.
  - charliebreslau 6y ago
    Higher abstraction -> less bugs. Forget low level, I beg you.
- oddity 6y ago
  I'm not sure this is a useful summary of the problem. I've seen an awful lot of code written in C and C++ that pisses away any and all advantage of using either. In general, I think software devs (and the software market) tend to value convenience over performance until it's too late, but the reasons why are so complicated and different per sector they'd make for a full PhD thesis and then some.
- rubatuga 6y ago
  PyPy is actually very fast, ~10x faster than standard python.

kuharich 6y ago

Past comments: https://news.ycombinator.com/item?id=20718315 https://news.ycombinator.com/item?id=20718315

JshWright 6y ago
Oh man, 2020 has been a long year... I totally forgot this had been posted before and I managed to repeat myself in the comments...

outworlder 6y ago

This matters more than one would think. I've once worked on a system that was objectively slow. Some actions would take seconds to complete. It's not like people would refuse the use the system, it was the only way to do their jobs. The public had no choice, either. Initially, I didn't think it was such a big deal. Yes it was a bit slow, but nothing _terrible_ and why did it matter, since there were so many other procedures that took way longer than the software step. It was a government facility, lots of red tape. Surely optimizing some of the paper processes would be more beneficial. But we optimized it anyway. Not because the UI was slow(which we didn't even measure directly), but because it was slow for a reason - backend processes were taking time, and resources. If we could optimize, we thought, we would save resources (and also increase the runway until we had to expand again, buy hardware and the like). First round of optimization was completed. Lots of low hanging fruits(many database-related). Testing indicated that the backend would be faster by almost an order of magnitude. Deployed. THE SYSTEM BECAME SLOWER. How was that possible? Maybe we had missed something. We found more bottlenecks, optimized those. Deployed again. Everything is slow again. What's happening?! We went to the 'field' - as in, talked to the users. Well, this is what we discovered: we saw the backend working harder - because the users were more productive! Instead of staying after the facilities were closed to the public and then catching up on whatever paperwork they were unable to enter in the system, they could process everything almost as fast as people came in. Which means that they could go home early. What we saw as "the system being slow again" was due to bad metrics - we were watching backend load, not UI response times. Because, admittedly, that didn't bother us directly. Not until we talked to the poor souls that had to use the system. Lots of async processes got triggered and queues filled up, but it didn't really matter to the users, as long as the UI said things were submitted and they could move on. After that, we optimized the heck out of all the UI interactions we could find.

eyelidlessness 6y ago
This is great for two reasons (and probably more): 1. It highlights that user impact determines success more than resource metrics. 2. It shows that assumptions infect even when you think you’ve accounted for assumptions. Honorable mention: don’t just prove the abstraction and call it done. It’s got to prove itself in real world scenarios before you can trust its claims!

joe_the_user 6y ago

I'd just mention another scenario where performance matters more than is imagined. It's common for people to reference Rich Sutton's The Bitter Lesson Of Machine Learning [1], which essentially says that brute force has always beaten "clever algorithms". I'd outline an alternative view to this. The development of "clever algorithms" in the GFAI days or pre-neural-nets computer visions days often didn't follow an approach where the different parts could be combined together in a fashion that was performant. It seems like the higher you go in CS theory, the more speed gets abstracted away. And the problems with that might be the real lesson here. [1] http://www.incompleteideas.net/IncIdeas/BitterLesson.html http://www.incompleteideas.net/IncIdeas/BitterLesson.html

obviouslynotme 6y ago

I'm old enough to remember Win32 programming in C/C++ because it was the only thing that worked. There was a problem though. Memory management, shitty standard library, and a non-existent packaging system. Java came around and gave you something that worked. Memory management? The runtime does it. Want to do X? Here is a library for X. These combined with academia moving over to Java killed new C++ development hard. It seemed good at the time. Java sucked but Widgets and MFC sucked harder. Qt wasn't that popular yet. There was only one problem with Java. Even on new machines, you would get noticeable random pauses doing simple things. This never happened in C++ apps even with full MFC bloat. The GC just wasn't that good yet. Programmers would also include FAR more code and libraries because it sped development up. Even today, C++ applications only include libraries if they absolutely have to because of how painful it is. All of C++'s disadvantages become advantages when you look at them from the lens of performance. Manual memory management means that even if you are slow, you are consistently slow. You don't get the peaks and valleys that really irritate humans who are incredibly sensitive to rhythm. Memory leaks are honestly not even a problem unless you have long running servers. Even then, you could honestly just restart. The near-complete lack of standard libraries and complete lack of a package system highly reduced the amount of fluff you had. If you wanted it in your software, you had to do it yourself. This led to very simple, non-pretty, static interface that just tried to look like Word without the Toolbar of Death. The best optimization has always been to Do Less Stuff. It's only going to get worse too. The same companies who think C++ is too complex for their programmers are going to laugh at Rust. People in Java or .NET shops aren't going to move over. "Native" is increasingly becoming a JavaScript space which has all the terrible performance of JavaScript usually combined with the slowness of internet connections. For good and ill, package management is now standard. Microsoft Office used to run fast on a 486 with megabytes of ram. Think about that. Are you a more complex or intensive program than Word? I bet that ePCR has far higher specs. The program running on it isn't inherently more complex. It's literally a form filler, but it isn't used because of how ridiculously bloated even the most basic software has become. In the 90's, you could have made that machine by installing Windows on a machine and programming a VB program in a few weeks that hooked up to a printer. It would have been more responsive than a state-of-the-art ePCR that sits unused today.

hansvm 6y ago

victorronin 6y ago

What would happen if you replace "performance" in this article with "not contrast enough UI" or "bad autocorrect" or "annoying background music"? Should this article have been "Good autocorrect matters"? The problem here isn't performance. The problem here is that the company which is building this software are so remote from end-user that they don't hear feedback. If they knew that performance is the problem and multidollar contract with some huge network of hospitals were at risk, I can bet you, this performance issues would have been fixed really fast.

eyelidlessness 6y ago
It isn’t as simple as that but I still want to recognize and applaud this response. You’re right, performance isn’t the fundamental issue, distance from user need and user pain is. Unfortunately even where that distance is short, mitigation can be hard to achieve. Understaffed and underfunded orgs can be wildly aware and even obsessed with shortcomings in their offerings and still fail to deliver improvements. I’ve worked in such orgs, I’ve seen overworked, deeply caring and empathetic and dedicated engineers trying to move mountains to fix (and have habitually been one myself). More to the point: unfortunately the software needs in the world, and the ways the world are underserved by software, are competing for resources and organizing talent with organizations that fundamentally don’t serve those needs. And both categories are competing in a limited pool, because software’s capabilities have outpaced the available talent to take advantage of those capabilities. Good for my bank account, I guess. But bad for people and the world we (I) inhabit. And bad for me too, probably even more than I know. Anyway this is far afield of parent comment’s point, but I felt it was a good place to add a little depth as an engineer who gives a damn but rarely sees the opportunity to apply damns.
- xupybd 6y ago
  I can't agree more. Everyone wants amazing software yesterday. They don't want to spend money to do it. The company that wins the bid tends to over promise on delivery dates and under supply resources to do it.
greggman3 6y ago

eyelidlessness 6y ago

One thing I don’t see mentioned here (haven’t looked at the past comments link but it’s worth surfacing here) is that requirements for many public RFPs, health care being right up there, is that since most people driving the process aren’t intimately familiar with software success and failure cases tend to refer to the intersection of tech and regulation. They don’t necessarily think about usability except in terms of a11y. Uptime, yes. Human experience interacting with it? Likely only if it resembles workflows that are similar and painful for them. This isn’t faulting these people defining these requirements! It’s a call to all the types of HN readership to put yourself more in the position to bring the knowledge that informs your contribution into the requirements process. You might never know that the success of the project you work on depends on your knowledge of color accuracy or time zones or particular patterns of abuse... until you get yourself a seat at the “first things first” table.

JshWright 6y ago

"If 0.1% of PCRs have mistakes that waste an hour of a doctor’s time, that’s 30,000 doctor-hours not spent on other patients." There is a 0.0% chance that this happens (in my opinion as a paramedic). If I had to guess, 0.1% is probably the rough order of magnitude of the frequency with which doctors look at the PCR at all. We give a verbal report which covers the important details. I would be hard-pressed to come up with an error that could possibly waste an hour of someone's time. "Did that quarter-second lag kill anyone? Was there someone who wouldn’t have died if the ePCR was just a little bit faster, fast enough to be usable? ... It could have saved the person the EMTs couldn’t get to because they lose an hour a week from extra PCR overhead." Similarly, no. There is no situation in EMS where 250ms is the difference between life and death. It's not like the tones drop for a call and we say 'gee, I wish I could go help that person, but I still have this chart to write...'. Performance absolutely matters (ironically, I'm a software developer for an EMR at my day job), but a little lag in an ePCR isn't going to kill anyone.

hxtk 6y ago
> There is no situation in EMS where 250ms is the difference between life and death. It's not like the tones drop for a call and we say 'gee, I wish I could go help that person, but I still have this chart to write...'. That wasn't how I read it. I may be incorrect, but my interpretation was that the 250ms didn't make the software too slow to be effective but rather too slow to be user friendly. The idea isn't that it directly killed people by being slow, but rather that it was not adopted because people didn't like using it, and on the paper alternative, mistakes were made that would have been impossible to make on the computer.
- JshWright 6y ago
  I don't have a choice about whether I use an ePCR or not, New York State (and, AFAIK, most other states) mandates it. The only place where PCR errors matter is on the witness stand... The PCR is certainly important, but any critical information is conveyed in a number of redundant ways, and I would be very surprised if there's been a single incidence of a PCR error resulting in a patient's death. PCRs are not treated with a great deal of trust, nor should they be (I say this as someone who has written thousands of them). We're dealing with incomplete and conflicting information, patients that actively lie (or, more charitably, forget) about their medical history, and in the case of critically sick patients (the ones that are at risk of dying in the first place) I am more focused on the acute management of their condition. No one expects a PCR to be accurate in every detail. That doesn't mean it's useless, but it also means the system expects there to be errors and has redundancies in place to account for that.

brundolf 6y ago

> But this isn’t “critical software”, either I strongly disagree. Anyone on the project would have (hopefully) known what it was being used for and how critical timing is for that task. Heck, the entire reason the project exists is to expedite the task. That translates directly to minimum-latency being a project constraint, so this to me just sounds like a project that failed to meet its constraints. If you're an application developer, you're generally going to have a clear idea of what the priorities are for your project and what does and doesn't matter (in terms of performance and otherwise). Maybe there's a case here for systems/library programmers erring on the side of performance because they genuinely don't know who will be using their code for what. But even then- if a library isn't fast enough (put differently: if the library's priorities diverge from the application's priorities), the application developer should know that and not use that library for their application. This trend of universalist performance-puritanism is exhausting. Performance is one of many priorities that a project may have. Know your target user, set your priorities accordingly, and develop your code in line with those priorities. No single priority gets to be so important across an entire field that everything else takes a back-seat.

jmnicolas 6y ago

I remember a comment here about a similar discussion about performances. The author made such a good praise of performance that I was half ready to learn ASM to code all my apps ... then he admitted he was using this Electron app because it was more featurefull than the native one ...

luckystarr 6y ago

I worry most people don't get the point of the Knuth's quote "Premature optimization is the root of all evil". Here is the full quote: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." What most people do is ALSO pass up optimizing that critical 3%, so software gets slower and slower. What he (probably) really meant is: "don't micro-optimize what a compiler can do better, optimize your algorithms and data-structures" Some common excuses for bad code: - Shuffling data around needlessly? Not a problem. It's fast enough. - The algorithm is bad. Not a problem. It's fast enough. - This is obviously bad. Not a problem. It already takes minutes, so a few more won't matter. - The code is slow. Not a problem. It's only used internally.

VBprogrammer 6y ago

I've recently been knees deep in optimising some old python multi processing code. I threw everything at it from trying to optimise the SQL queries it made to pre-fetching multiple requests to its child processes. In the end I broke out pyinstrument and found some logging in a loop which was taking up a big chunk of parent time. Fixing that gave a 2x performance increase. I went back and tested the various changes I'd made to that point and thankfully found that most of them were needed to sustain that performance improvement but it was a good reminder to break out the profiler first, not last.

noisy_boy 6y ago

> It wasn’t even that slow. Something like a quarter-second lag when you opened a dropdown or clicked a button. But it made things so unpleasant that nobody wanted to touch it. Considering the no. of fields on that form, with that kind of lag, I'll be ditching it too. I mean most of it is check-boxes; just replicate the damn thing on html. Though without knowing more about the setup, I would guess that hardware with terrible input is also involved.

MaxBarraclough 6y ago

A slight nitpick: > The ambulance I shadowed had an ePCR. Nobody used it. I talked to the EMTs about this, and they said nobody they knew used it either. Lack of training? No, we all got trained. Crippling bugs? No, it worked fine. Paper was good enough? No, the ePCR was much better than paper PCRs in almost every way. It just had one problem: it was too slow. That is a crippling bug. The UI is a soft real-time system, [0] and it's doing such a poor job of meeting its deadlines that the user considers the system to be unusable. If you're writing an autopilot system, it's not enough for the system to eventually make the right decision, it must arrive at the right decision before the deadline. Failure to do so would by definition qualify as a bug. > Most of us aren’t writing critical software. But this isn’t critical software, either: nobody will suddenly die if it breaks. Won't they? If the software corrupts the patient data, someone could die, right? Elsewhere the article essentially says as much: > An error might waste valuable time as nurses chase invisible problems or ignore obvious ones. Worst case, it leads to the wrong treatment. In emergency situations these mistakes can be fatal. [0] https://en.wikipedia.org/wiki/Real-time_computing#Soft https://en.wikipedia.org/wiki/Real-time_computing#Soft edit I see brundolf's comment already makes some of these points

jspash 6y ago
I would argue that the 250ms lag mentioned in the article was not the reason the ePCR system was perceived as being slow. Consider the new trend in login forms these days whereby you are forced to enter you username or email THEN press a button THEN enter your password THEN press another button. What used to be simple is now no longer simple. Why is it like this? To accommodate the x% of people who seem to get confused in some manner when presented with "too many choices". I forget the reasoning now, and disagree 1000% but don't want to sidetrack my argument any further. Anyhow... compare the original form to an imagined GUI since we're not presented with the software to make a proper comparison. If you needed to fill out the paper form quickly you can tick..tick...tick..tick..write a bit.tick...tick..read..write.etc. Now with the software, does it use a mouse? Probably not. It's most likely a touch screen. Possibly a tablet. So now every choice required more interaction. More choices. Opening a dropdown? So you mean to say the developers have decided to hide important information until you request it? The paper version has everything you ever need to know at a glance. One side of a sheet, no need to even flip it over. This is all conjecture, but I experience this type of thing all the time when a software "solution" comes to fix a real-world "problem". It can be done well. Most UK Govt websites are incredibly well-done IMHO. But usually they're not.

legulere 6y ago

For a reference, this is how fast you should be: - animations under 10 ms - reacting to user interactions under 50ms https://web.dev/rail/#focus-on-the-user https://web.dev/rail/#focus-on-the-user