Live data from Hacker News

Maybe people do care about performance and reliability

buttondown.email

101–110 of 280 posts

Re: Maybe people do care about performance and reliability

#101

Earlier quoted context omitted.

How bloated software can become is limited by available hardware resources. 20-30 years ago typical RAM size / CPU core count where much smaller than nowadays. If you run desktop software written 20 years ago on modern hardware it would work much faster than modern desktop software with comparable functions (not always, but quite often). But I'd agree that there was plenty bloated software which run slow on hardware…

> with comparable functions (not always, but quite often). Is that really the case? Are 2010 skype and 2022 discord comparable in terms of functionality? Are 2000 winamp and 2022 spotify app comparable? Todo app 15 years ago was a simple CRUD app. Today todo app has to do CRUD, sync, offline mode, public API, integrations with popular services, collaborative projects and support 6 platforms. People whine about bloate…

Yes, they are all equivalent. There are variations in specific features but it should be obvious how irrelevant that is.

The present day "apps" you describe are bloated because they bundle an entire web browser and more, maybe the equivalent of a container, to run the little sliver of JS/html that presents the UI to the user.

The reason they are bundled like this is to enable web developers to work on them.

Re: Maybe people do care about performance and reliability

#102
post #5

I think performance simply just isn't on the radar of a big chunk of devs these days, especially self-taught ones. Front-end wise, what with the trend of using frameworks (react/vue/etc) & a billion lines of javascript downloaded from npm, it'd probably be too much of a task to even begin profiling.

IMO it's unfair to blame the developers. Almost every developer I know loves working on performance stories. It's one of the few times we get to use our deeper technical and algorithmic skills and get a clear metric to optimize for. However, businesses are reluctant to prioritize that work and get impatient when they don't see new "features". I worked on a project where PMs would constantly complain to me about a par…

I dunno, I run into a lot of devs on reddit/here/etc that argue "who cares about performance just spin up more containers! I just wanna write {insert slow interpreted language here}."

Re: Maybe people do care about performance and reliability

#103
post #57

Earlier quoted context omitted.

My IDE auto-saves as you make changes, yet I still mash ctrl+s frequently. I think it's mostly games that gave me the habit though. PC gaming has always been a gauntlet.

> My IDE auto-saves as you make changes This gave me shutters. Maybe it is some sort of manual transmission-type feeling of control, but that is terrifying to me. Something about that feeling of owning when the source file is changed.

The most annoying thing for me is that the idea of take something similar, make my changes to it, and save it under a different name only mangles the original file in today's world.

Re: Maybe people do care about performance and reliability

#104

The idea that software wasn't bloated and slow 20,30+ years ago is just myth. Everything was bloated and slow. MS Word in the 90s and 00s would regularly crash and take your file with you, and it often took minutes to start up. Yes, there were some brilliant counterexamples, just as there are today. But most software today is far more enjoyable and rapid to use than that from previous eras. While the software isn't a…

> MS Word in the 90s and 00s [...] often took minutes to start up.

And how quickly would the latest version of Microsoft Word start up on 90s-era PC?

Okay, so it wouldn't start up at all because the computer would not have enough memory, among other things. Let's say we built the absolute closest computer that could still technically run modern MS Office. We'd choose the absolute slowest CPU that can still boot Windows 10, the smallest amount of memory, and so on. It would still be many times faster than a 90s-era PC.

How quickly would modern Office open on that hardware? What about Office 95?

Re: Maybe people do care about performance and reliability

#105
Its a mix.

I'm sitting here trying to replicate a service across multiple zones this mornin— oh, it's not morning any more sigh — and, well,

  Code: ReconcileVMSSAgentPoolFailed
  Message: We are unable to serve this request due to an internal error
At some point/level, Azure can't¹, so I can't. There's GCP, but high switching costs. (¹this is a fractal error, too. Part incompetence, part societal and economic factors way out of certainly my control.)

But absolutely there is incompetence. I fielded this, this week: "the tests broke", "oh, sorry about that. I've introduced a bug. a while later It's fixed now." "the test is still broke for me?" "… you need to pull the fix…?"

I've got another dev staunchly refusing to enable the logging necessary to print tracebacks, … while simultaneously being perplexed by a bug we're facing. IDK what's causing the bug either … but, IDK, let's get some logs in the meantime?

Higher ups wondering "why can't anyone answer technical questions? How are our devs so incompetent that they don't know the answers?" after the entire team that managed the component to which the question is directed at has been laid off.

I've answered questions in the form of,

  A: We do X. Here's a screenshot. 
  Me: Where in your screenshot is X?
  A: Oh, you're right.
Often enough that sometimes I wonder if ChatGPT hasn't already replaced some of the people around me.

Re: Maybe people do care about performance and reliability

#106
post #54

Earlier quoted context omitted.

>but launching things is mostly bound by the hard drive speed. which got slower and slower taking swap speed with it, which slowed down everything you were actually using. You'd defrag the drive regularly and that wouldn't do it so you'd have to wipe and reinstall from scratch. And that was some hours of work but like having a brand new machine again when you were done. You couldn't believe how bad it had degraded to…

Oh man, I forgot about defragging. There was something quite satisfying about knowing your computer was “tidying things up” behind the scenes.

As recently as 2015 I was advising people that if you finish your work too early to go home, you should spend your time on updating our docs, defragging your hard drive, and reading the docs for your tools (eg, learning keyboard shortcuts or optional flags).

Defragging is one of those clear cases for time shifting things from your high value time to your low value time.

Re: Maybe people do care about performance and reliability

#107

Its a mix. I'm sitting here trying to replicate a service across multiple zones this mornin— oh, it's not morning any more sigh — and, well, Code: ReconcileVMSSAgentPoolFailed Message: We are unable to serve this request due to an internal error At some point/level, Azure can't¹, so I can't. There's GCP, but high switching costs. (¹this is a fractal error, too. Part incompetence, part societal and economic factors wa…

I bet you these developers can rotate the shit out of a red/black tree though! Thanks LeetCode-centered hiring processes!

Re: Maybe people do care about performance and reliability

#108

A big part of the problem in my opinion, is that people are generally not interested in investing (money, time, effort) in technology. They focus almost exclusively on products. The short term is always given a much higher priority than long term. If someone invents a much better way (faster, easier, cheaper) to do some key part of a widely used product (operating system, database, file system, network protocol), the…

> You can't just find a way to do something 10x faster and expect others to flock to it.

I have learned this the hard way. People are generally loss averse and resistant to change so making things better is often an uphill struggle.

As an example, I have worked on improving a build tool that is notoriously loathed in part for its poor performance. Part of the problem was that it was a jvm based tool and the jvm has terrible startup performance when loading lots of library code (the tool also made it easy to bring in dependencies so even small projects would often pull in massive amounts of vendor code). The only way to get a reasonably tight feedback loop under those constraints is to run tests in a persistent jvm process that can reuse the loaded classes from prior runs. The difference between using a cached jvm and a fresh jvm could easily be the difference between your tests running in tens of milliseconds or multiple seconds. I produced benchmarks that proved this.

But one problem is that any resource leaks in your code or the vendor code will eventually cause the jvm to run out of memory (which often would be a slow process of gradually degrading performance). For this and other reasons, people would often opt out of the in-process test running and fork a fresh jvm with each test run even though it could easily cost them hours of time over the course of a week. The problem was that using the in-process runner required stronger programming discipline. My claim was that code that could reliably run inside of the build tool without resource leaks is more desirable than code that cannot. It is also not particularly more difficult to write, but it does require skill and discipline. There was no tool to statically detect resource leaks so the burden does fall on the individual programmer. It was an exercise in frustration to try and explain the value proposition and argue with people with very different priorities from me so I walked away from the project but to this day it saddens me how much time is being sacrificed to the altar of poor programming discipline.

Re: Maybe people do care about performance and reliability

#109
post #54

Earlier quoted context omitted.

>but launching things is mostly bound by the hard drive speed. which got slower and slower taking swap speed with it, which slowed down everything you were actually using. You'd defrag the drive regularly and that wouldn't do it so you'd have to wipe and reinstall from scratch. And that was some hours of work but like having a brand new machine again when you were done. You couldn't believe how bad it had degraded to…

Oh man, I forgot about defragging. There was something quite satisfying about knowing your computer was “tidying things up” behind the scenes.

Oh, when I was younger I was mesmerized by watching all of the little squares in the defrag tool change color and move around. It was like someone tidying your room for you!

Re: Maybe people do care about performance and reliability

#110

The idea that software wasn't bloated and slow 20,30+ years ago is just myth. Everything was bloated and slow. MS Word in the 90s and 00s would regularly crash and take your file with you, and it often took minutes to start up. Yes, there were some brilliant counterexamples, just as there are today. But most software today is far more enjoyable and rapid to use than that from previous eras. While the software isn't a…

> The idea that software wasn't bloated and slow 20,30+ years ago is just myth. Everything was bloated and slow. MS Word in the 90s and 00s would regularly crash and take your file with you, and it often took minutes to start up. Yes, there were some brilliant counterexamples, just as there are today. But most software today is far more enjoyable and rapid to use than that from previous eras. Install Windows 2000 and…

On today's hardware, or on hardware of the time?

Things like word used to be much better in speed of the interface - it used to take fewer clicks to do stuff

Post reply on HN