Past comments: https://news.ycombinator.com/item?id=20718315
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...
Performance Matters (2019)
31–40 of 75 posts
Re: Performance Matters (2019)
#32I'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.…
> Memory leaks are honestly not even a problem unless you have long running servers. Not your main point, but having to kill a program or an OS and restart whatever I was working on because some process can't be bothered to give back memory it doesn't need (and that I now do need) is a major pain.
Luckily, the same programs that leak memory are probably the ones that handle crashes poorly
Re: Performance Matters (2019)
#33I'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.…
> Memory leaks are honestly not even a problem unless you have long running servers. Firefox is a counterexample to this statement. Rust appeared because experienced Firefox developers simply couldn't manage C memory manually, C memory with garbage collection, C++ memory manually, or C++ memory with garbage collection.
Yeah, kinda. Rust is meant to solve memory unsafety, which is an even worse problem than memory leaks, especially when you're running untrusted code.
Re: Performance Matters (2019)
#34This 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 pro…
As a user forced to use many apps and websites with a terrible user experience, I conclude that you can certainly have well-communicated loading times without me hating the product.
However, I will always avoid - if I can - using a product where the UI itself is slow, sluggish or bad. This includes many modern websites and also quite a few apps.
Responsiveness is the key. If I click on something, then something needs to happen. People can deal with a loading bar, but everyone gets terribly confused and / or annoyed by a sluggish drop-down menus, buttons that seem to fire only after a couple of seconds, or, my favorite, a scrolling action that is either sluggish or leads to load processes that interrupt itself.
Re: Performance Matters (2019)
#35Software 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 softwa…
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.
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?
Re: Performance Matters (2019)
#36Earlier quoted context omitted.
> 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 pro…
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…
>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.
Lmao. I like this perspective. I guess all if life is basically a workaround to not dying.
Re: Performance Matters (2019)
#37I'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.…
> Memory leaks are honestly not even a problem unless you have long running servers. Firefox is a counterexample to this statement. Rust appeared because experienced Firefox developers simply couldn't manage C memory manually, C memory with garbage collection, C++ memory manually, or C++ memory with garbage collection.
And still, Firefox is less efficient and less secure than Chrome or Safari.
Re: Performance Matters (2019)
#38Earlier quoted context omitted.
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.
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?
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.
Re: Performance Matters (2019)
#39What 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 mul…
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 w…
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.
Re: Performance Matters (2019)
#40> 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.